Re: [Qemu-devel] [libvirt] Qemu, libvirt, and CPU models

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3243 bytes --]

On 03/07/2012 03:26 PM, Eduardo Habkost wrote:
> Thanks a lot for the explanations, Daniel.
> 
> Comments about specific items inline.
> 

>>>   - How can we make sure there is no confusion between libvirt and Qemu
>>>     about the CPU models? For example, what if cpu_map.xml says model
>>>     'Moo' has the flag 'foo' enabled, but Qemu disagrees? How do we
>>>     guarantee that libvirt gets exactly what it expects from Qemu when
>>>     it asks for a CPU model? We have "-cpu ?dump" today, but it's not
>>>     the better interface we could have. Do you miss something in special
>>>     in the Qemu<->libvirt interface, to help on that?
> 
> So, it looks like either I am missing something on my tests or libvirt
> is _not_ probing the Qemu CPU model definitions to make sure libvirt
> gets all the features it expects.
> 
> Also, I would like to ask if you have suggestions to implement
> the equivalent of "-cpu ?dump" in a more friendly and extensible way.
> Would a QMP command be a good alternative? Would a command-line option
> with json output be good enough?

I'm not sure where we are are using "-cpu ?dump", but it sounds like we
should be.

> 
> (Do we have any case of capability-querying being made using QMP before
> starting any actual VM, today?)

Right now, we have two levels of queries - the 'qemu -help' and 'qemu
-device ?' output is gathered up front (we really need to patch things
to cache that, rather than repeating it for every VM start).  Then we
start qemu with -S, query QMP, all before starting the guest (qemu -S is
in fact necessary for setting some options that cannot be set in the
current CLI but can be set via the monitor) - but right now that is the
only point where we query QMP capabilities.

If QMP can alter the CPU model prior to the initial start of the guest,
then that would be a sufficient interface.  But I'm worried that once we
start qemu, even with qemu -S, that it's too late to alter the CPU model
in use by that guest, and that libvirt should instead start querying
these things in advance.  We definitely want a machine-parseable
construct, so querying over QMP rather than '-cpu ?dump' sounds like it
might be nicer, but it would also be more work to set up libvirt to do a
dry-run query of QMP capabilities without also starting a real guest.

> 
> But what about the features that are not available on the host CPU,
> libvirt will think it can't be enabled, but that _can_ be enabled?
> x2apic seems to be the only case today, but we may have others in the
> future.

That's where having an interface to probe qemu to see what capabilities
are possible for any given cpu model would be worthwhile, so that
libvirt can correlate the feature sets properly.

> 
> That answers most of my questions about how libvirt would handle changes
> on CPU models. Now we need good mechanisms that allow libvirt to do
> that. If you have specific requirements or suggestions in mind, please
> let me know.

I'll let others chime in with more responses, but I do appreciate you
taking the time to coordinate this.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]