On Mon, Aug 19, 2013 at 2:47 PM, Eric Blake <eblake@xxxxxxxxxx> wrote:
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 theNot just that, but we JUST took a patch that enhanced the
> virConnectBaselineCPU APIs? It would probably have to be another API
> entirely but at least similar in naming scope.
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).
Listing all the capabilities of all the emulators in the existing
>
> 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.
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.
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
Doug Goldstein
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list