On Thu, Jul 18, 2013 at 02:37:33PM +0100, Daniel P. Berrange wrote:
On Mon, Jul 15, 2013 at 01:45:56PM -0600, Don Dugger wrote:
[snip]
We've been going back & forth a while now, and I don't think we're ever
going to agree on this matter.
To move this forward, I'm prepared to accept an API addition that lets
apps get the full list of CPU feature flags, provided that there is no
change to the existing default behaviour of our APIs. eg it should be
an opt-in decision
You took the words out of my mouth :-), I was actually thinking about
proposing something along these lines. I agree, this is a good compromise
and I'll work up a patch along the lines you propose.
IIUC, in essence you want a way to take the host CPU description (as
generated in the XML for virConnectGetCapabilties), and expand this
see the full set of features that are able to be presented to the guest.
I think this could probably be done by adding a flag to the existing
virConnectBaselineCPU API. eg something like
capsxml = virConnectGetCapabilties()
cpuxml = ...extract the <cpu> bit of capsxml...
newxml = virConnectBaselineCPU(conn, &cpuxml, 1,
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES)
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano(a)n0ano.com
Ph: 303/443-3786