[Qemu-devel] default qemu64 &Co CPUs makes no sense?

[Qemu-devel] default qemu64 &Co CPUs makes no sense?

[Michael Tokarev]

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

Re: [Qemu-devel] default qemu64 &Co CPUs makes no sense?

[Paolo Bonzini]

Il 09/05/2012 18:54, Michael Tokarev ha scritto:
> 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.

Leaving aside the discussions on TCG, yes, this makes no sense for kvm.
 You should use kvm32 and kvm64 instead.

Paolo

Re: [Qemu-devel] default qemu64 &Co CPUs makes no sense?

[Michael Tokarev]

On 10.05.2012 11:30, Paolo Bonzini wrote:
> Il 09/05/2012 18:54, Michael Tokarev ha scritto:
>> 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.
> 
> Leaving aside the discussions on TCG, yes, this makes no sense for kvm.
>  You should use kvm32 and kvm64 instead.

In that case the question turns into a different one: why qemu64
is default with -enable-kvm?  Either way it makes no sense at all,
and that's whole my point.

/mjt

Re: [Qemu-devel] default qemu64 &Co CPUs makes no sense?

[Paolo Bonzini]

Il 10/05/2012 09:46, Michael Tokarev ha scritto:
>>> >> 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.
>> > 
>> > Leaving aside the discussions on TCG, yes, this makes no sense for kvm.
>> >  You should use kvm32 and kvm64 instead.
> In that case the question turns into a different one: why qemu64
> is default with -enable-kvm?  Either way it makes no sense at all,
> and that's whole my point.

Yes, perhaps that can be changed.  It's not trivial due to
backwards-compatibility (need to keep -cpu qemu64 for versioned machine
types <= 1.1), but doable.

Paolo