[libvirt] [Qemu-devel] libvirt<->QEMU interfaces for CPU models
Eduardo Habkost
ehabkost at redhat.com
Mon Mar 25 20:37:46 UTC 2013
On Fri, Mar 01, 2013 at 11:56:00PM +0100, Jiri Denemark wrote:
[...]
> > > > = Getting information about CPU models =
> > > >
> > > > Requirement: libvirt uses the predefined CPU models from QEMU, but it needs to
> > > > be able to query for CPU model details, to find out how it can create a VM that
> > > > matches what was requested by the user.
> > > >
> > > > Current problem: libvirt has a copy of the CPU model definitions on its
> > > > cpu_map.xml file, and the copy can be out of sync in case CPU models in QEMU
> > > > change. libvirt also assumes that the set of features on each model is always
> > > > the same on all machine-types, which is not true.
> > > >
> > > > Challenge: the resulting CPU features depend on lots of factors, including
> > > > the machine-type.
> > > >
> > > > Workaround: start a paused VM and query for the CPU device information
> > > > after the CPU was created.
> >
> > I just noticed another problem here, but this gave me an idea that would
> > help solve the "enforce" error reporting problem:
> >
> > Problem: "qemu -machine <M> -cpu <model>" will create CPU objects
> > where the CPU features are _already_ filtered based on host
> > capabilities.
>
> Ah, it seems logical now that you mention it :-)
>
> > * Using "enforce" wouldn't solve it, because then QEMU would abort, and
> > QMP would be unavailable.
> >
> > Solution: we could have a CPU object property like
> > "removed-features" that would have the list of features that were
> > disabled because they are not supported by the host (and would make
> > "enforce" fail).
> >
> > * This would solve the problem above and also be a machine-friendly
> > way to check for possible "enforce" errors.
> >
> > * In other words: instead of "enforce", libvirt could use "check"
> > instead of "enforce", and before unpausing the VM (or even starting
> > migration), it should first check if the "removed-features" property is
> > empty.
> >
> > Would that work for you?
>
> Yes, that seems like it could work. In fact, it seems much better than
> using enforce and trying to deal with aborted QEMU.
To make the libvirt logic simpler, we could do this: have a "force" mode
(in addition to check/enforce), that wouldn't filter any CPU feature
based on host capabilities. This way libvirt wouldn't need any
non-trivial logic to combine the "f-*" flags and "removed-features" to
find out the CPU model details.
Then libvirt would need to look only at "f-*" to find out the CPU model
details at probing time (as long as "force" is used at probing time),
and just make sure "removed-features" is empty before starting the VM
(optionally parsing its value or checking the "f-*" property values, to
find out which features are missing exactly).
--
Eduardo
More information about the libvir-list
mailing list