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@xxxxxxxxx Ph: 303/443-3786 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list