[libvirt] [PATCH V2] Expose all CPU features in host definition

[Jiri Denemark]

On Fri, Jun 14, 2013 at 12:32:35 -0600, Don Dugger wrote:
> On Fri, Jun 14, 2013 at 03:06:52PM +0200, Jiri Denemark wrote:
> > I was just trying to say that it doesn't provide anything more than
> > "it's supported by the host CPU", which gives mostly no value in the
> > context of libvirt. Can you explain more what the use case is in which a
> > virt client would need to know what specific feature are supported by
> > host CPU? I feel like we should avoid people from being under the
> > impression that they can actually use the CPU capabilities for checking
> > whether a host can run guests that require specific CPU features.
> 
> The specific use case I'm trying to address is a cloud environment where,
> with hundreds of hosts, you might want to schedule an instance to a host
> that supports a particular HW acceleration, like AES/NI.  I agree, what
> I `really` want is an API that shows the capabilities of a specific guest
> that could be created on the host but, absent that API, at least knowing
> that a host doesn't support the feature is more information than I can get
> right now.

Hmm, fair enough. Let's wait a few days for Daniel to return from
vacation in case he wants to express his opinion here.

> > Moreover, there's one thing that makes this issue even more complicated.
> > As the CPU model is the most useful part of host CPU capabilities (it
> > should be the best CPU model supported by the host), I wanted to extend
> > the probing code to select the right model even if it's missing some
> > features that we expect to be supported by that model. In other words,
> > if host CPU is, e.g., SandyBridge but has some basic feature disabled,
> > we would detect it as the best model which did not have the disabled
> > feature, which is not optimal. We'd ideally detect the CPU as
> > SandyBridge with just the feature disabled. That is, another reason for
> > having feature list relative to the CPU model. On the other hand, it
> > might be hard or even impossible to do without breaking compatibility
> > and perhaps even doubtful without involving emulator, which would make
> > it impossible to do within capabilities XML.
> 
> If I understand you, you're proposing that you report the host as being
> a SandyBridge when it doesn't support all SandyBridge features?  I don't
> like that idea as it seems really confusing.  Taken to the extreme, this
> would mean you could take a Nehalem host and report it as a SanyBridge
> that lacks some features.  I don't see the point of that.

Yes and no :-) I'd like to report the CPU as a SandyBridge if it really
is a SandyBridge but lacks a feature that we require to be present for
us to detect the CPU as a SandyBridge. There are (or at least were)
features that can actually be disabled on the host, e.g., by BIOS and I
remember that doing so may result in that particular feature to be
disabled in CPUID. For example, if NX (not sure if that's the right
example that is actually masked from CPUID) is disabled, than the CPU
still is a SandyBridge but libvirt would detect it as something generic
and old as NX is part of all modern CPU models libvirt supports.
However, as I said, this could be hard or even impossible to do in a
compatible manner.

Jirka