Re: [libvirt] [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases
On Wed, Jul 25, 2012 at 06:43:25PM -0500, Anthony Liguori wrote:
Eduardo Habkost <ehabkost(a)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