On Mon, Aug 19, 2013 at 2:47 PM, Eric Blake <ebl...@redhat.com> wrote:
> On 08/19/2013 01:22 PM, Doug Goldstein wrote: > > On Mon, Aug 19, 2013 at 1:19 PM, Giuseppe Scrivano <gscri...@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. > 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
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
