From: Eduardo Habkost <ehabkost@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: libvir-list@redhat.com, Jiri Denemark <jdenemar@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>
Subject: Re: [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names & compatibility aliases
Date: Thu, 26 Jul 2012 10:24:56 -0400 [thread overview]
Message-ID: <20120726142456.GE27859@shell.eng.rdu.redhat.com> (raw)
In-Reply-To: <501078B1.8080103@suse.de>
On Thu, Jul 26, 2012 at 12:52:33AM +0200, Andreas Färber wrote:
> Am 25.07.2012 20:18, schrieb Eduardo Habkost:
> > This adds version number to CPU model names on the "pc-<version>"
> > machine-types, so we can create new models with bug fixes while keeping
> > compatibility when using older machine-types.
> >
> > When naming the existing models, I used the last QEMU version where the
> > model was changed (see summary below), but by coincidence every single
> > one was changed on QEMU-1.1.
> >
> > - Conroe, Penryn, Nehalem, Opteron_G1, Opteron_G2, Opteron_G3:
> > added on 0.13, changed on 1.1
> > - Westmere, SandyBridge, Opteron_G4: added on 1.1
> >
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > ---
> > hw/pc_piix.c | 56 ++++++++++++++++++++++++++++++++++++
> > sysconfigs/target/cpus-x86_64.conf | 18 ++++++------
> > 2 files changed, 65 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> > index 0c0096f..ef3840f 100644
> > --- a/hw/pc_piix.c
> > +++ b/hw/pc_piix.c
> > @@ -349,6 +349,18 @@ static void pc_xen_hvm_init(ram_addr_t ram_size,
> > }
> > #endif
> >
> > +/* CPU aliases for pre-1.2 CPU models */
> > +#define V1_1_CPU_ALIASES \
> > + { "Conroe", "Conroe-1.1" }, \
> > + { "Penryn", "Penryn-1.1" }, \
> > + { "Nehalem", "Nehalem-1.1" }, \
> > + { "Westmere", "Westmere-1.1" }, \
> > + { "SandyBridge", "SandyBridge-1.1" }, \
> > + { "Opteron_G1", "Opteron_G1-1.1" }, \
> > + { "Opteron_G2", "Opteron_G2-1.1" }, \
> > + { "Opteron_G3", "Opteron_G3-1.1" }, \
> > + { "Opteron_G4", "Opteron_G4-1.1" },
> > +
> > static QEMUMachine pc_machine_v1_2 = {
> > .name = "pc-1.2",
> > .alias = "pc",
> > @@ -356,6 +368,10 @@ static QEMUMachine pc_machine_v1_2 = {
> > .init = pc_init_pci,
> > .max_cpus = 255,
> > .is_default = 1,
> > + .cpu_aliases = (CPUModelAlias[]) {
> > + V1_1_CPU_ALIASES
> > + {NULL, NULL},
> > + },
> > };
> >
> > #define PC_COMPAT_1_1 \
> [...]
> > diff --git a/sysconfigs/target/cpus-x86_64.conf b/sysconfigs/target/cpus-x86_64.conf
> > index cee0ea9..14c7891 100644
> > --- a/sysconfigs/target/cpus-x86_64.conf
> > +++ b/sysconfigs/target/cpus-x86_64.conf
> > @@ -1,7 +1,7 @@
> > # x86 CPU MODELS
> >
> > [cpudef]
> > - name = "Conroe"
> > + name = "Conroe-1.1"
> > level = "2"
> > vendor = "GenuineIntel"
> > family = "6"
> [snip]
>
> So where are the actual differences between, e.g., Conroe-1.1 and
> Conroe? I'd expect we need either an additional string applying
> parameter presets such as maybe "x2apic=off" or a nested list of
> (property, value) pairs.
There are no differences yet, until we make updates in the Conroe model.
If we have to make any change (to fix a bug, for example), we would
create a "Conroe-1.2" CPU model, and make the "pc-1.2" machine-type
alias "Conroe" to "Conroe-1.2" while keeping the older machine-types
using "Conroe-1.1".
>
> As long as there's no concept for actually modelling versioned CPUs, I
> consider this RFC stage and not worth merging yet...
What do you mean by "no concept for actually modelling versioned CPUs"?
You mean there's no use-case or reason for versioning them, or that the
series don't model the versioning properly?
--
Eduardo
next prev parent reply other threads:[~2012-07-26 14:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 18:18 [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases Eduardo Habkost
2012-07-25 18:18 ` [Qemu-devel] [QEMU PATCH 1/3] vl.c: extract qemu_machine_init() function Eduardo Habkost
2012-07-25 22:18 ` [Qemu-devel] [libvirt] " Eric Blake
2012-07-30 16:19 ` Eduardo Habkost
2012-07-25 18:18 ` [Qemu-devel] [QEMU PATCH 2/3] per-machine-type CPU model alias system Eduardo Habkost
2012-07-25 22:46 ` Andreas Färber
2012-07-25 18:18 ` [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names & compatibility aliases Eduardo Habkost
2012-07-25 22:52 ` Andreas Färber
2012-07-26 14:24 ` Eduardo Habkost [this message]
2012-07-26 14:31 ` Andreas Färber
2012-07-26 14:48 ` Eduardo Habkost
2012-07-31 13:22 ` Igor Mammedov
2012-07-31 13:44 ` Eduardo Habkost
2012-07-26 14:33 ` Jiri Denemark
2012-07-26 14:54 ` Eduardo Habkost
2012-07-25 23:43 ` [Qemu-devel] [QEMU PATCH 0/3] versioned CPU models / per-machine-type aliases Anthony Liguori
2012-07-26 13:53 ` Eduardo Habkost
2012-07-26 14:06 ` Andreas Färber
2012-07-26 14:29 ` Eduardo Habkost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120726142456.GE27859@shell.eng.rdu.redhat.com \
--to=ehabkost@redhat.com \
--cc=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=gleb@redhat.com \
--cc=jdenemar@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).