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

[Don Dugger]

On Thu, May 30, 2013 at 01:48:32PM +0200, Jiri Denemark wrote:
> On Tue, May 28, 2013 at 16:11:57 -0600, Don Dugger wrote:
> > [V2 - Improve the error handling]
> > 
> > I've opened BZ 697141 on this as I would consider it more
> 
> I guess you meant BZ 967141.
> 
> > a bug than a feature request.  Anyway, to re-iterate my  
> > rationale from the BZ:                                 
> >                       
> > 
> > The virConnectGetCapabilities API describes the host capabilities
> > by returning an XML description that includes the CPU model name 
> > and a set of CPU features.  The problem is that any features that
> > are part of the CPU model are not explicitly listed, they are    
> > assumed to be part of the definition of that CPU model.  This
> > makes it extremely difficult for the caller of this API to check
> > for the presence of a specific CPU feature, the caller would have
> > to know what features are part of which CPU models, a very       
> > daunting task.                                                 
> >               
> > This patch solves this problem by having the API return a model
> > name, as it currently does, but it will also explicitly list all
> > of the CPU features that are present.  This would make it much  
> > easier for a caller of this API to check for specific features.
> 
> It's actually the desired behavior and not a bug. We went that way for
> several reasons. First, given how QEMU/KVM works, the fact that a
> CPU feature is detected by libvirt in host CPU and reported in
> capabilities XML does not mean that the feature will be available to
> guests. This is the reason why we have virConnectCompareCPU. You can
> create a guest CPU definition you would like to see in a guest and call
> virConnectCompareCPU on it to check if that guest CPU can be run on that
> particular host. And providing all features in capabilities XML would
> just make the XML larger with no practical benefit.

The fact that host CPU features at not necessarily available to a guest
has no impact on whether or not we report all features that the host
supports, that issue remains in either case.  Also, I created some
test programs and, for test cases of CPU definitions that were identical,
incompatible or a subset of the host the virConnectCompareCPU API worked
the same with or without my patch to expose all host CPU features.

So far the only argument I see against explicitly exposing all features
is that it makes the XML description slightly larger.  Given that the
increased size exposes useful information I think that is a good trade
off to make.

> 
> In other words, as Martin already said, we don't really want to expand
> the CPU model in capabilities XML. However, implementing a new API that
> would take a CPU XML definition and return the exact set of CPU features
> (including those included in the CPU model) seems like a useful
> addition.

Independent from the discussion of what the virConnectGetCapabilites API
should return I agree, an API to decompose a specified CPU XML
definition seems like a good idea, I'll work on creating a second patch
for that.

> 
> Jirka
> 

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