On 11/10/2011 09:46 AM, Avi Kivity wrote:
(re-adding cc)
On 11/09/2011 09:35 PM, Walter Haidinger wrote:
Am 09.11.2011 14:40, schrieb Avi Kivity:
Actually, it looks like an OpenBSD bug. According to the AMD
documentation:
Well, the OpenBSD developers are very confident that is
a bug in the KVM cpu emulation and _not_ in OpenBSD.
Basically they say that [despite -cpu host], the emulated
cpu does not look like a real, but _non-existant_ cpu.
Virtualization should look like _existing_ hardware.
That is true. But OpenBSD is not following the vendor's recommendation
for how software should access the hardware.
Since the list archive at
http://marc.info/?l=openbsd-misc&m=132077741910464&w=2
lags a bit, I'm attaching some parts of the thread below:
However, please remember it's OpenBSD, so the tone is, let's just
say, rough.
Less than expected, actually.
The panic you hit is for an msr read, not a write. I'm aware those
registers are read-only. The CPUID check isn't done, it matches on
all family 10 and/or higher AMD processors. They're pretending to be
an AMD K10 processor. On all real hardware I've tested this works
fine. If you wish to be pedantic, patches are welcome.
Avi, thanks for caring of that.
The manual is clear here: no CPUID bit, no MSRs. Beside that the
emulated ACPI tables probably also don't provide any info here, right?
The fact that it runs: "on all family 10 and/or higher AMD processors"
is just an empiric observation, not a law. You would be astonished what
can be fused off...
We had a similar discussion here with unconditional AMD Northbridge PCI
accesses when detecting certain AMD CPU family/model/steppings in the
Linux kernel already (...but every AMD CPU has a northbridge...)
We (as virtualization guys) should not step back so easily here,
especially if the spec is so clear. That spec argument should actually
appeal to the OpenBSD guys, too. I got the impression that their design
is, well, actually well designed.
So they're actually open to adding the cpuid check.
They sent me a patch as a workaround, which:
The previous patch avoids touching the msr at all if ACPI indicates
speed scaling is unavailable, this should prevent your panic.
with -cpu host, OpenBSD dmesg showed the 1100T:
cpu0: AMD Phenom(tm) II X6 1100T Processor ("AuthenticAMD" 686-class, 512KB L2 cache) 3.31 GHz cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT
...
bios0: vendor Bochs version "Bochs" date 01/01/2007 bios0: Bochs
Bochs
They shouldn't be pretending to be AMD, especially if that emulation
is very incompatible.
but the bug is in the Linux KVM:
They're pretending to be an AMD K10 processor.
Exactly. What they are doing is wrong. They are pretending to be a
AMD K10 processor _badly_, and then they think they can say "oh, but
you need to check all these other registers too". A machine with that
setup has never physically existed.
Is this all because I used -cpu host?
-cpu host is not to blame, you could get the same result from other
combinations of cpu model and family.
I'll look at adding support for this MSR; should be simple. But in
general processor features need to be qualified by cpuid, not by model.
I guess emulating part of P-states will open up a can of worms. Beside
the generic MSRs (0xC001006[1-3]) there are actual family specific ones
which are selected by the CPUID family. So you would end up emulating
them, too. I have a hard time to think about a strategy how to emulate
this in general. So unless there is a real framework for dealing with
P-state "hints" from the guest OS, I'd be reluctant with quick and dirty
emulations.
Thanks,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
