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
