Re: [libvirt] [PATCH V2] Expose all CPU features in host definition
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.
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.
Jirka