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:
>> 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:
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
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