Alexander Graf wrote:
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'm not interested in mimicing qemu, I'm interested in mimicing a real
cpu. kvm is not part of qemu.
Many (most?) msrs cannot be emulated in userspace.
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?
An msr is a cpu resource. I don't see how you can define a new cpu
resource without changing the cpu implementation, which is in the
kernel. If they want to communicate with userspace, let them use mmio
or pio.
Look at the Xen interface. You write to one cpu's MSR, and the cpu
writes a page in guest memory. It doesn't fit; a much better interface
would have been mmio.
I don't want to break layering just for Xen, so I'm trying to find an
alternative.
--
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
