Re: Userspace MSR handling

[Avi Kivity <avi@redhat.com>]

Gerd Hoffmann wrote:
>
>>> - what about connecting the guest driver to xen netback one day?  we 
>>> don't
>>> want to go through userspace for that.
>
> You can't without emulation tons of xen stuff in-kernel.
>
> Current situation:
>  * Guest does xen hypercalls.  We can handle that just fine.
>  * Host userspace (backends) calls libxen*, where the xen hypercall
>    calls are hidden.  We can redirect the library calls via LD_PRELOAD
>    (standalone xenner) or function pointers (qemuified xenner) and do
>    something else instead.
>
> Trying to use in-kernel xen netback driver adds this problem:
>  * Host kernel does xen hypercalls.  Ouch.  We have to emulate them
>    in-kernel (otherwise using in-kernel netback would be a quite
>    pointless exercise).

Or do the standard function pointer trick.  Event channel notifications 
change to eventfd_signal, grant table ops change to copy_to_user().

>
>> One way or another, the MSR somehow has to map in a chunk of data
>> supplied by userspace. Are you suggesting an alternative to the PIO
>> hack?
>
> Well, the "chunk of data" is on disk anyway:
> $libdir/xenner/hvm{32,64}.bin
>
> So a possible plan to attack could be "ln -s $libdir/xenner 
> /lib/firmware", let kvm.ko grab it if needed using 
> request_firmware("xenner/hvm${bits}.bin"), and a few lines of kernel 
> code handling the wrmsr.  Logic is just this:
>
> void xenner_wrmsr(uint64_t val, int longmode)
> {
>     uint32_t page = val & ~PAGE_MASK;
>     uint64_t paddr = val & PAGE_MASK;
>     uint8_t *blob = longmode ? hvm64 : hvm32;
>     cpu_physical_memory_write(paddr, blob + page * PAGE_SIZE,
>                               PAGE_SIZE);
> }
>
> Well, you'll have to sprinkle in blob loading and caching and some 
> error checking.  But even with that it is probably hard to beat in 
> actual code size.  

This ties all guests to one hypercall page implementation installed in 
one root-only place.

> Additional plus is we get away without a new ioctl then.


Minimizing the amount of ioctls is an important non-goal.  If you 
replace request_firmware with an ioctl that defines the location and 
size of the hypercall page in host userspace, this would work well.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.