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@xxxxxxxxx > Ph: 303/443-3786 > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale n0ano@xxxxxxxxx Ph: 303/443-3786 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list