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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org