From: Jamie Lokier <jamie@shareable.org>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>, qemu-devel@nongnu.org
Subject: Re: [kvm-devel] [Qemu-devel] Re: expose host CPU features to guests
Date: Sun, 9 Sep 2007 13:47:18 +0100 [thread overview]
Message-ID: <20070909124718.GE24240@mail.shareable.org> (raw)
In-Reply-To: <46E3A618.7030505@qumranet.com>
Avi Kivity wrote:
> Well, the guest will invoke its own workaround logic to disable buggy
> features, so I see no issue here.
The guest can only do this if it has exactly the correct id
information for the host processor (e.g. "This is an Intel Pentium Pro
model XXX"), not just the list of safe to use CPU features.
This isn't possible in a virtualisation cluster of many different CPUs
where the point is to advertise the common set of cpuid features, and
for the guest images to be able to migrate between different CPUs in
the cluster.
Then, the common cpuid features must be found by combining the
/proc/cpuinfo from each node in the cluster. But I guess that's
separate from the part of Qemu we are discussing; it would be done by
another program, preparing the -cpuid argument.
But sometimes it's good to run a simple guest (e.g. someone's pet OS
project, or anything written for Intel only which was more common in
the past) which doesn't have all the detailed obscure workarounds of
something like Linux, but still be able to take advantage of the
workarounds and obscure knowledge in the host.
The alternative is Qemu itself may end up having to have some of these
obscure workarounds :/
For example, the sysenter instruction is advertised on early Pentium
Pros, but it doesn't work. Linux removes it from the features in
/proc/cpuinfo, and doesn't use it. But some guests simply don't get
that obscure, and use it if cpuid advertises it. Of course, they
don't work on a _real_ early Pentium Pro. But it would be nice if
they did work without anything special when run in Qemu on such a
host. That's an old chip which I happen to know about, but I'm sure
there are more modern similar issues.
Perhaps there could be two options then: "-cpuid host-os", and "-cpuid
host-cpuid". I would suggest making "host" an alias for "host-os",
but I wouldn't object if it were an alias for "host-cpuid" or didn't
exist at all, so you had to choose one.
-- Jamie
next prev parent reply other threads:[~2007-09-09 12:47 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-05 17:45 [Qemu-devel] expose host CPU features to guests danken
2007-09-05 19:26 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2007-09-05 19:34 ` Avi Kivity
2007-09-05 19:44 ` Daniel P. Berrange
2007-09-06 0:30 ` Paul Brook
2007-09-06 8:46 ` Avi Kivity
2007-09-07 10:47 ` Jamie Lokier
2007-09-09 7:51 ` [kvm-devel] [Qemu-devel] " Avi Kivity
2007-09-09 12:47 ` Jamie Lokier [this message]
2007-09-09 12:55 ` Avi Kivity
2007-09-09 13:07 ` Jamie Lokier
2007-09-09 13:14 ` Avi Kivity
2007-09-09 15:25 ` Paul Brook
2007-09-09 15:29 ` Avi Kivity
2007-09-09 15:47 ` Jamie Lokier
2007-09-09 16:12 ` Paul Brook
2007-09-09 16:38 ` Avi Kivity
2007-09-10 16:53 ` Jamie Lokier
2007-09-10 7:40 ` [Qemu-devel] expose host CPU features to guests: Take 2 Dan Kenigsberg
2007-09-10 11:47 ` Natalia Portillo
2007-09-10 12:01 ` Dan Kenigsberg
2007-09-07 16:18 ` Natalia Portillo
2007-09-11 19:48 ` Luke -Jr
2007-09-10 17:16 ` Jamie Lokier
2007-09-24 17:41 ` [Qemu-devel] expose host CPU features to guests: Take 3 Dan Kenigsberg
2007-09-25 1:28 ` andrzej zaborowski
2007-09-25 8:48 ` [kvm-devel] " Dan Kenigsberg
2007-09-25 9:01 ` Avi Kivity
2007-09-25 9:19 ` J. Mayer
2007-09-25 9:31 ` Avi Kivity
2007-09-25 10:40 ` Avi Kivity
2007-09-25 11:09 ` J. Mayer
2007-09-25 11:36 ` Avi Kivity
2007-09-25 12:05 ` Fabrice Bellard
2007-09-25 13:07 ` Jocelyn Mayer
2007-09-25 13:12 ` Avi Kivity
2007-09-25 13:27 ` Dan Kenigsberg
2007-09-25 15:54 ` Jamie Lokier
2007-09-25 16:15 ` Avi Kivity
2007-09-25 12:51 ` Paul Brook
2007-09-25 13:13 ` Avi Kivity
2007-09-25 9:29 ` Fabrice Bellard
2007-10-07 12:38 ` [Qemu-devel] x86 -cpu option: Take 4 Dan Kenigsberg
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=20070909124718.GE24240@mail.shareable.org \
--to=jamie@shareable.org \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
--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).