Re: Userspace MSR handling

[Avi Kivity <avi@redhat.com>]

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