On 24.05.2009, at 14:07, Avi Kivity <avi@xxxxxxxxxx> wrote:
Alexander Graf wrote:
On 22.05.2009, at 22:11, Ed Swierk <eswierk@xxxxxxxxxxxxxxxxxx>
wrote:
I'm experimenting with Gerd's excellent work on integrating Xenner
into Qemu (http://git.et.redhat.com/?p=qemu-kraxel.git). I'm using
it
to boot a FreeBSD guest that uses the Xen paravirtual network
drivers.
Decoupling the Xen PV guest support from the hypervisor really
simplifies deployment.
The current implementation doesn't yet support KVM, as KVM has to
handle a Xen-specific MSR in order to map hypercall pages into the
guest physical address space. A recent thread on this list discussed
the issue but didn't come to a resolution.
Does it make sense to implement a generic mechanism for handling
MSRs
in userspace? I imagine a mechanism analogous to PIO, adding a
KVM_EXIT_MSR code and a msr type in the kvm_run struct.
I'm happy to take a stab at implementing this if no one else is
already working on it.
I think it's a great idea.
I was thinking of doing something similar for ppc's HIDs/SPRs too,
so a userspace app can complement the kernel's vcpu support.
Also by falling back to userspace all those MSR read/write patches
I send wouldn't have to go in-kernel anymore :)
I'm wary of this. It spreads the burden of implementing the cpu
emulation across the kernel/user boundary. We don't really notice
with qemu as userspace, because we have a cpu emulator on both
sides, but consider an alternative userspace that only emulates
devices and has no cpu emulation support. We want to support that
scenario well.
Moreover, your patches only stub out those MSRs. As soon as you
implement the more interesting bits, you'll find yourself back in
the kernel.
Agreed. The one thing that always makes my life hard is the default
policy on what to do for unknown MSRs. So if I could (by having a
userspace fallback) either #GP or do nothing, I'd be able to mimic
qemu's behavior more closely depending on what I need.
I definitely wouldn't see those approaches conflicting, but rather
complementing each other. If your kvm using userspace app needs to act
on a user-defined msr, you wouldn't want him to contact reshat to
implement an ioctl for rhel5 just for this msr, do you?
So imho instead of #gp'ing falling back to userspace would be great.
Alex
I agree however that the Xen hypercall page protocol has no business
in kvm.ko. But can't we implement it in emu? Xenner conveniently
places a ring 0 stub in the guest, we could trap the MSR there and
emulate it entirely in the guest.
--
error compiling committee.c: too many arguments to function
--
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
