Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models

[Eduardo Habkost]

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