Re: Userspace MSR handling

[Avi Kivity <avi@redhat.com>]

Ed Swierk wrote:
> On Mon, May 25, 2009 at 4:20 AM, Avi Kivity <avi@redhat.com> wrote:
>   
>> Device drivers have no business writing to cpu model specific registers.  I
>> hate to bring that fugliness to kvm but I do want to support Xen guests.
>>
>> It should have been implemented as mmio.  Maybe implement an ioctl that
>> converts rdmsr/wrmsr to equivalent mmios?
>>     
>
> Converting MSRs to IO sounds fine, but a generic mechanism, with a new
> ioctl type and all the bookkeeping for a dynamically-sized list of
> MSR-to-MMIO mappings, seems like overkill given the puny scope of the
> problem. All the Xen HVM guest needs is a single, arbitrary MSR that
> when written generates an MMIO or PIO write handled by userspace. If
> this requirement is unique and we don't expect to find other guests
> that similarly abuse MSRs, could we get away with a less flexible but
> simpler mechanism?
>   

I agree, it's stupid.

> What I have in mind is choosing an unused legacy IO port range, say,
> 0x28-0x2f, and implementing a KVM-specific MSR, say, MSR_KVM_IO_28,
> that maps rdmsr/wrmsr to a pair of inl/outl operations on these ports.
> Either MMIO or PIO would work, but I'm assuming it's safer to grab
> currently-unused IO ports than particular memory addresses.
>   

It's just as bad.

> That odor you smell is the aroma of hardcoded goop, but I'm trying to
> find a solution that doesn't burden KVM with a big chunk of code to
> solve a one-off problem.
>   

Will it actually solve the problem?

- can all hypercalls that can be issued with 
pv-on-hvm-on-kvm-with-a-side-order-of-fries be satisfied from userspace?
- what about connecting the guest driver to xen netback one day?  we 
don't want to go through userspace for that.

We can consider catering to Xen and implementing that MSR in the kernel, 
if it's truly one off.

-- 
error compiling committee.c: too many arguments to function