On Wed, Jul 25, 2012 at 06:43:25PM -0500, Anthony Liguori wrote:
> Eduardo Habkost <ehabkost@xxxxxxxxxx> writes:
>
> > Hi,
> >
> > This is the first try at a simple system to make the CPU model definitions
> > versioned (to allow them to get bug fixes while allowing migration from older
> > versions and keeping command-line compatibility), and per- machine-type aliases
> > for compatibility.
> >
> > The lack of CPU model versioning is blocking multiple bug fixes that are
> > necessary on CPU model definitions, but can't be included today because they
> > would break migration.
> >
> > Later, after this gets in (or at least gets some feedback), I plan to send a
> > proposal for a machine-friendly CPU feature / CPU model probing interface that
> > libvirt could use.
>
> This isn't the right approach. The CPU properties should be exposed as
> QOM properties which then allows the machine type globals to be used to
> control stuff like this.
I would like to use global properties for this, but the obstacles I have
found were:
- As far as I can see in the code, global properties are usable only by
qdev objects, and CPUs were not qdevfied yet
- The per-machine-type properties I need to set are for CPU models, not
CPUs.
- For example: if we fix the Nehalem CPU model by changing the "level"
field, we need to make the pc-1.1 and lower machine-types to keep
the old "level" value, but only on the Nehalem CPU model
>
> Is there a specific set of properties you want to control? As long as
> it's a small number, we can start with that and get something in shape
> for 1.2.
The main bugs that need this to allow us to fix it are:
- Some CPU models have a too low "level" field and need it to be
increased on newer machine-types (and kept the same on older
machine-types).
- Some subtle bugs need the "model" field to be changed, too. See:
http://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02545.html
- Some features may need to be added or removed from some CPU models.
- Example: SandyBridge has tsc-deadline enabled on the config file,
but it simply does not enable the feature on qemu-1.1. The fix will
require disabling tsc-deadline on the pc-1.1 machine type.
Anyway, I think the number of properties is not necessarily a problem:
the problem is to have the proper infra-structure so the CPU
model/machine-type compatibility can be implemented using global
properties. If we have something in place to allow that, supporting 3 or
20 properties seems to be equally feasible.
>
> Regards,
>
> Anthony Liguori
>
> >
> > Eduardo Habkost (3):
> > vl.c: extract qemu_machine_init() function
> > per-machine-type CPU model alias system
> > x86: pc: versioned CPU model names & compatibility aliases
> >
> > hw/boards.h | 13 +++++++++
> > hw/pc_piix.c | 56 ++++++++++++++++++++++++++++++++++++
> > sysconfigs/target/cpus-x86_64.conf | 18 ++++++------
> > vl.c | 28 +++++++++++++++++-
> > 4 files changed, 105 insertions(+), 10 deletions(-)
> >
> > --
> > 1.7.10.4
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list