From: Michael Tokarev <mjt@tls.msk.ru>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: Julien Cristau <jcristau@debian.org>
Subject: [Qemu-devel] default qemu64 &Co CPUs makes no sense?
Date: Wed, 09 May 2012 20:54:22 +0400 [thread overview]
Message-ID: <4FAAA13E.10308@msgid.tls.msk.ru> (raw)
Default qemu64 x86 CPU in qemu is somewhat interesting.
It has fixed family=6, model=2, and uses host CPUID
if kvm is enabled, or AMD CPUID if not.
So for case when it is run on intel box with kvm enabled,
it corresponds to PentiumII CPU, which has no suppot of
64bits whatsoever, at all. Ie, it is a well-known CPU
model, and it is well-known that model does not support
64bit operations. Yet qemu enables corresponding CPU
feature flags (lm etc). This confuses some software,
for example, qmp:
http://gmplib.org:8000/gmp-5.0/file/244cd8619153/mpn/x86_64/fat/fat.c#l193
If we run on AMD host, or we don't enable kvm, it will
be some AMD family 6 CPU, which also does not support
64bit mode at all (seen in the same gmp source file).
And in case kvm is enabled, and we run on some other CPU
(not intel and not amd), we'll have some other CPU model,
which might exist or might not, which may make some sense
or may not, etc - we simple don't know.
This, I think, is a bug: qemu should not use a well-known
CPU identification (family & model) without 64bit mode
support for its 64bit CPU. Qemu may use some non-existing
CPU ID in this context (and hope it will not be used by some
future CPU), or it may use ID of some existing, but actually
64bit-capable, CPU here.
There's another issue in this context: it is the changing
CPU Vendor when kvm is enabled. As far as I can see, the
default qemu vCPU is supposed to be migratable, as it chooses
some "common denominator" subset of features of various CPUs.
But the vendor ID matches HOST CPU vendor ID if kvm is enabled,
which makes CPU vendor to change during cross-vendor migration,
which may confuse the guest too much. So I think we should
stop reporting HOST CPU Vendor ID to guest here.
Should both be fixed by choosing some sane CPUID for a default
qemu64 CPU (and qemu32 too - I didn't check if qemu32 or other
common CPU definitions makes sense or not) and never reporting
HOST CPU Vendor ID for it?
Why this fam=6, model=2 has been chosen anyway, in this commit:
commit 14ce26e755135e80f3726d42a5a887723d615291
Author: bellard <bellard@c046a42c-6fe2-441c-8c8c-71466251a162>
Date: Mon Jan 3 23:50:08 2005 +0000
x86_64 target support
?
http://gmplib.org/list-archives/gmp-bugs/2012-May/thread.html
contains current incarnation of this discussion as seen from GMP
side. I'd say both - qemu and GMP - are buggy and should be
fixed. Qemu side as per above, and GMP side by changing abort()s
in the code referrenced above to just break, to let default (ie,
non-optimized) CPU setup to be actually used.
Thanks,
/mjt
next reply other threads:[~2012-05-09 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 16:54 Michael Tokarev [this message]
2012-05-10 7:30 ` [Qemu-devel] default qemu64 &Co CPUs makes no sense? Paolo Bonzini
2012-05-10 7:46 ` Michael Tokarev
2012-05-10 7:49 ` Paolo Bonzini
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=4FAAA13E.10308@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=jcristau@debian.org \
--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).