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

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(a)n0ano.com Ph: 303/443-3786 -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list