On Wed, Mar 07, 2012 at 04:07:06PM -0700, Eric Blake wrote: > > > > (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). That's what I feared. I was wondering if we had a better machine-friendly interface to make some of these queries, today. > 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. This is probably true, and I don't see this being changed in the near future. Even if we fix that for CPU initialization, there are many other initialization steps involved that would have to be reworked to allow all capability querying to be made to the same Qemu process that would run the VM later. > 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. On the other hand, with QMP we would have a better interface that could be used for all other queries libvirt has to run. Instead of running Qemu multiple times for capability querying, just start a single Qemu process and make the capability queries using QMP. I don't know if this was discussed or considered before. > > > > 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. Yes. The issue currently is that many things don't depend just on static CPU model or machine-type definitions, libvirt has to know what capabilities the kernel provides and Qemu will really be able to use. It will be a long way to fix this. Some features are simply not configurable yet, even on the command-line. They are just automatically used by Qemu when provided by the kernel. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list