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

[Don Dugger]

Jiri-

Have you had a chance to look over this email?  Barring any counter
examples I still think my patch is appropriate.

On Fri, May 31, 2013 at 01:04:17PM -0600, Don Dugger wrote:
> 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
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 

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