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@n0ano.com Ph: 303/443-3786