On Mon, Aug 19, 2013 at 2:47 PM, Eric Blake <eblake@redhat.com> wrote:
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
CPUs the HV can emulate. In the future it can have support for other
the 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.
Right. I more meant adding a new API and not overloading the exist virConnectCapabilities() but a virConnectHypervisorCapabilities() that would allow us to query specific instances. I always wanted a way to see if a qemu had qxl support (and by extension spice). I'm just roughing this here: char *virConnectHypervisorCapabilities(virConnectPtr conn, const char *hv, int flags /* future */); where the 2nd arg would take the value from <emulator> from virConnectCapabilities(). or char *virConnectHypervisorCapabilities(virConnectPtr conn, virHypervisorsUghName hv, int flags /* future */); where the prior type is an enum that has VIR_HYPERVISOR_QEMU_ARM, VIR_HYPERVISOR_QEMU_X86. I don't really like the enum simply because there's so many kvm and qemu binaries you can have on the system it'd really be hard to match an enum to a specific one. We could inject another arg in between the 2nd and 3rd and that be the enum for data we're looking for. Like VIR_HYPERVISOR_CPU, VIR_HYPERVISOR_VIDEO, VIR_HYPERVISOR_SYSTEM (would return back 440fx and q35 for x86 based qemu's and something like vexpress-a9 for ARM). In a way I see this complimenting virConnectCapabilities() with virConnectHypervisorCapabilties() with some of the current items in the former appearing in the later (specifically from the <guest> section). The former would primarily have to roll of describing the system as a whole while the later would have the job of describing the specific emulator you're using. -- Doug Goldstein