Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases

[Eduardo Habkost <ehabkost@redhat.com>]

On Wed, Jul 25, 2012 at 06:43:25PM -0500, Anthony Liguori wrote:
> Eduardo Habkost <ehabkost@redhat.com> 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