[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-typ
Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases
Thu, 26 Jul 2012 09:53:33 -0400
On Wed, Jul 25, 2012 at 06:43:25PM -0500, Anthony Liguori wrote:
> Eduardo Habkost <address@hidden> 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
- 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
- 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
- Some subtle bugs need the "model" field to be changed, too. See:
- 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.
> 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(-)
> > --
> > 220.127.116.11
Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases, Anthony Liguori, 2012/07/25
- Re: [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases,
Eduardo Habkost <=