From: Jamie Lokier <jamie@shareable.org>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host
Date: Wed, 24 Jun 2009 22:39:44 +0100 [thread overview]
Message-ID: <20090624213944.GD14121@shareable.org> (raw)
In-Reply-To: <20090624211200.GD15263@random.random>
Andrea Arcangeli wrote:
> Hi Jamie,
>
> thanks for review!
>
> On Wed, Jun 24, 2009 at 06:29:34PM +0100, Jamie Lokier wrote:
> > So your patch should make no difference to Linux guests. Did you
> > check Linux behaviour? Does Windows ignore the vendor id?
>
> Maybe I wasn't clear enough, this patch only makes a difference for
> KVM. KVM switches the vendor id to Intel when run on vmx host. It
> definitely makes a difference to linux guest, without this patch 32bit
> linux run as guest on top of KVM has sep disabled in /proc/cpuinfo and
> isn't using sysenter (just like windows, hence the skype crash). I
> verified 32bit linux guest has sep enabled with this patch applied
> when run on KVM on top of intel.
That was not at all clear.
What's missing is a comment saying "KVM changes this vendor id to
Intel when run on a VMX-capable host".
So what happens if you have a guest which worked fine under QEMU, then
breaks because it sees a changed vendor id when you run it under KVM?
I guess the guest, being Windows, tells you to make a phone call to
Microsoft because you changed the CPU, if you're out of luck.
It looks like it could be a KVM mis-feature.
Is the changing vendor id actually useful for anything, without
updating the family/model/stepping at the same time? E.g. does it
make some guest things work, even though other parts of the cpuid
don't reflect the host?
> Another approach is to switch model to 3 along with vendor_id in KVM
> but because qemu is already using 6/3/3 when emulating a 32bit x86
> hardware, I don't think this is simpler and more consistent.
No, I'm happy with 6/3/3. Like that part of the patch :-)
Although... there aren't any 64-bit Pentium Pros, so maybe 6/3/3 is a
bit... small? :-)
Now I'm just wondering why the vendor id needs to change dynamically,
if the other cpuid fields aren't changed. If that's useful, then at
least a comment around the qemu64 CPU type to say that happens would
be good. If that's not really a useful feature, then better not to do
it.
Maybe it's not useful any more, as "-cpu host" can be used instead (a
recent patch). That had better not break Skype :-)
For Windows guests, which are sensitive to CPU changes, I prefer not
to change CPU type dynamically without the user knowing. Even with
"-cpu host", I hope (eventually) the chosen CPU type will be stored
when saving/migrating and loaded exactly the same on other hosts, when
it's technically possible.
-- Jamie
next prev parent reply other threads:[~2009-06-24 21:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-23 16:21 [Qemu-devel] allow sysenter on 32bit guests running on vmx host Andrea Arcangeli
2009-06-24 17:29 ` Jamie Lokier
2009-06-24 17:48 ` Filip Navara
2009-06-24 21:13 ` Andrea Arcangeli
2009-06-24 21:12 ` Andrea Arcangeli
2009-06-24 21:39 ` Jamie Lokier [this message]
2009-06-24 22:32 ` Andrea Arcangeli
2009-06-25 8:11 ` [Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host) Andre Przywara
2009-06-25 8:29 ` [Qemu-devel] KVMs default CPU type Avi Kivity
2009-06-26 0:42 ` [Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host) Andrea Arcangeli
2009-06-26 1:06 ` Andrea Arcangeli
2009-06-25 17:39 ` [Qemu-devel] allow sysenter on 32bit guests running on vmx host Paul Brook
2009-06-25 21:02 ` Andrea Arcangeli
2009-06-25 22:12 ` Paul Brook
2009-06-25 23:27 ` Andrea Arcangeli
2009-06-25 23:49 ` Paul Brook
2009-06-26 0:06 ` Andrea Arcangeli
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=20090624213944.GD14121@shareable.org \
--to=jamie@shareable.org \
--cc=aarcange@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).