On 08/19/2013 01:22 PM, Doug Goldstein wrote:
On Mon, Aug 19, 2013 at 1:19 PM, Giuseppe Scrivano <gscrivan@redhat.com>wrote:
--- I have started working on:
https://bugzilla.redhat.com/show_bug.cgi?id=916786
Before I split it in a series of commits, test it better and then proceed to virt-manager, are you ok with this idea?
I'm wondering if this could some how be done as an extension to the virConnectBaselineCPU APIs? It would probably have to be another API entirely but at least similar in naming scope.
Not just that, but we JUST took a patch that enhanced the virConnectBaselineCPU API to take a flag argument: https://www.redhat.com/archives/libvir-list/2013-August/msg00150.html Looking at it further, it looks like the REAL problem to be solved is "given an emulator, which CPU models can I pass by name, and what CPU features will those models imply". It is completely independent of how the implementation stores it (that is, the fact that our qemu driver stores a cpu_map.xml lookup table should NOT be used in determining the function name).
Or potentially generic-ify this a bit more to make it like a virConnectHypervisorCapabilities() where right now it just returns back the CPUs the HV can emulate. In the future it can have support for other things if we need it to.
Listing all the capabilities of all the emulators in the existing virConnectHypervisorCapabilities may be too much XML for one RPC call; so a new API that lets us focus on one particular emulator is worthwhile. But yes, this is a better scheme to be copying from - we want a command where the user specifies an emulator, and the output is XML describing that emulator's capabilities according to what libvirt can expose. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org