[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models |
Date: |
Mon, 25 Mar 2013 17:37:46 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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