On 08/19/2013 01:22 PM, Doug Goldstein wrote: > On Mon, Aug 19, 2013 at 1:19 PM, Giuseppe Scrivano <gscrivan@xxxxxxxxxx>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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list