From: Eduardo Habkost <ehabkost@redhat.com>
To: qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>,
libvir-list@redhat.com
Subject: Re: [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names & compatibility aliases
Date: Thu, 26 Jul 2012 10:54:38 -0400 [thread overview]
Message-ID: <20120726145438.GB7834@shell.eng.rdu.redhat.com> (raw)
In-Reply-To: <20120726143336.GK2038855@orkuz.home>
On Thu, Jul 26, 2012 at 04:33:36PM +0200, Jiri Denemark wrote:
> On Wed, Jul 25, 2012 at 15:18:43 -0300, Eduardo Habkost wrote:
> > 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
>
> Hi Eduardo,
>
> What models would be listed by "qemu-system-x86_64 -cpu ?"? Only non-versioned
> model aliases or full names with versions or both?
Just the full names. The aliases are machine-type properties, but I
didn't see a good place to list them on the help text. (suggestions are
welcome)
Anyway, "-cpu ?" and "-cpu ?dump" are interfaces for humans. libvirt
will require a new interface that allows it to query the CPU model
versions and the aliases. But defining this interface will be possible
only after we settle on the design of the system inside QEMU. (e.g. if
we implement it based on global properties, there may be no concept of
"versions" and "aliases" at all, and we may have to rethink the way the
QEMU<->libvirt interface will look like).
--
Eduardo
next prev parent reply other threads:[~2012-07-26 14:55 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
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 [this message]
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=20120726145438.GB7834@shell.eng.rdu.redhat.com \
--to=ehabkost@redhat.com \
--cc=gleb@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).