On Mon, Aug 19, 2013 at 2:47 PM, Eric Blake <eblake(a)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(a)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