This is in response to this bug report: https://gitlab.com/qemu-project/qemu/-/issues/191
The generic 'qemu64' and 'max' CPUs currently defined to report a family/model/stepping that approximately corresponds to an AMD K7 vintage architecture. The K7 series predates the introduction of 64-bit support by AMD in the K8 series. This has been reported to lead to LLVM complaints about generating 64-bit code for a 32-bit CPU target LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it! The bug report is fairly limited, but it suggests LLVM looks at the family/model/stepping and decides it to be 32-bit, despite qemu64 reporting it is 64-bit capable. I've not reproduced this myself, however, so I'm largely trusting the original reporter's diagnosis Of course interpreting the family/model/stepping only makes sense with scoped to the reported vendor ID. Under TCG, the vendor is honoured, but AFAICT, under KVM the vendor defined by the QEMU model model is ignored and the real host vendor passed through. This will make the chosen family/model/stepping non-sensical when run under KVM on an Intel host. None the less these patches change to report a CPUID with the family, model and stepping taken from a AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ which is one of the first 64-bit AMD CPUs. This is at least more accurate in terms of the static CPU model definition, even if it is still nonsense in the case where KVM overrides the vendor to be non-AMD. Daniel P. Berrangé (2): i386: use better matching family/model/stepping for 'qemu64' CPU i386: use better matching family/model/stepping for 'max' CPU hw/i386/pc.c | 6 +++++- target/i386/cpu.c | 12 +++++++++--- 2 files changed, 14 insertions(+), 4 deletions(-) -- 2.31.1
