On 09.01.2009, at 20:05, Anthony Liguori wrote:
Avi Kivity wrote:
Kevin Wolf wrote:
Hi,
let's start with the scenario I tried to use: I have two levels of
virtualization. On the physical hardware I run a Linux with KVM.
The KVM
guest is a Win2k3 VM which runs VirtualPC. In VirtualPC I try to
run a
Linux again (openSUSE 11.1 to be specific, but that shouldn't
matter).
The boot menu comes up nicely and so on, but early in the kernel
boot it
crashes:
EIP is at kvm_deferred_mmu_op+0x46/0xbf
Call Trace:
[<c0117f79>] kvm_mmu_write+0x59/0x61
[<c011bad9>] set_pte_vaddr+0x95/0xec
[<c011b3b2>] __native_set_fixmap+0x1d/0x24
[<c054ae5b>] test_wp_bit+0x24/0x6c
[<c054b6b1>] mem_init+0x295/0x2b8
[<c053a8a3>] start_kernel+0x262/0x31f
Now obviously this is a KVM function where there should be none. The
problem seems to be that VirtualPC doesn't intercept cpuid and
thus the
VirtualPC guest sees the KVM cpuid values where it better wouldn't.
Consequently, it turns on the paravirt support for KVM which is
exactly
wrong and leads to the crash on the first hypercall.
The guest has no chance to detect correctly if it's running
directly on
KVM or if there is another virtualization layer which can't emulate
cpuid. So the fix must involve the mechanism itself. Alex has
suggested
to change the interface to use a KVM-specific MSR instead of cpuid
as
these should be handled by any virtualization software. I'm
copying him
so he can take over for the details, I just want to get the
discussion
started.
So... Comments? Suggestions? Patches? ;-)
Gaa. Looks like cpuid is totally broken by first-generation
virtualization products.
Not at all. There's no reason that a JIT'ing virtualization product
can't rewrite CPUID to a function call and then mask off unsupported
bits. It's a bug in the virtualization product if it doesn't do this.
Isn't one of the great things about virtualization the fact that you
can do things you can on real hardware in the virtual machine? While
I'm not exactly a fan of VirtualPC, I would still like it to work in
KVM, as that's what real hardware is capable of.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
