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

[Don Dugger]

On Mon, Jun 17, 2013 at 10:27:36AM +0200, Jiri Denemark wrote:
> 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.

So, any progress 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
> 

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano at n0ano.com
Ph: 303/443-3786