Re: Userspace hypercalls?

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>> I've never really thought much about them until now.  What's the case
>> for supporting userspace hypercalls?
>>
>> The current way the code works is a little scary.  Hypercalls that
>> aren't handled by kernelspace are deferred to userspace.  Of course,
>> kernelspace has no idea whether userspace is actually using a given
>> hypercall so if kernelspace needs another one, the two may clash.
>>
>> AFAICT, the primary reason to use hypercalls is performance.  A vmcall
>> is a few hundred cycles faster than a PIO exit.  In the light-weight
>> exit path, this may make a significant different.  However, when going
>> to userspace, it's not only a heavy-weight exit but it's also paying the
>> cost of a ring transition.  The few hundred cycle savings is small in
>> comparison to the total cost so I don't think performance is a real
>> benefit here.
>>   
>
> Actually the heavyweight exit is much more expensive than the ring 
> transition.
>
>> The hypercall namespace is much smaller than the PIO namespace, and
>> there's no "plug-and-play" like mechanism to resolve conflict.  PIO/MMIO
>> has this via PCI and it seems like any userspace device ought to be
>> either a PCI device or use a static PIO port.  Plus, paravirtual devices
>> that use PCI/PIO/MMIO are much more likely to be reusable by other VMMs
>> (Xen, QEMU, even VMware).
>>
>> In the future, if we decide a certain hypercall could be done better in
>> userspace, and we have guests using those hypercalls, it makes sense to
>> plumb the hypercalls down.
>>
>> My question is, should we support userspace hypercalls until that point?
>>   
>
> I've already mentioned this but I'll repeat it for google:  allowing 
> hypercalls to fallback to userspace gives you flexibility to have 
> either a kernel implementation or a userspace implementation for the 
> same functionality.  This means a pvnet driver can be used either 
> directly with a virtual interface on the host, or having some 
> userspace processing in qemu.  Similarly, pvblock can be processed in 
> the kernel for real block devices, or in userspace for qcow format 
> files, without the need to teach the kernel about the qcow format 
> somehow.
>
> Dor's initial pv devices are implemented in qemu with a view to having 
> a faster implementation in the kernel, so userspace hypercalls are on 
> the table now.
>

Thinking a little more about this, it isn't about handling hypercalls in 
userspace, but about handling a virtio sync() in userspace.

So how about having a KVM_HC_WAKE_CHANNEL hypercall (similar to Xen's 
event channel, but assymetric) that has a channel parameter.  The kernel 
handler for that hypercall dispatches calls to either a kernel handler 
or a userspace handler.  That means we don't need a separate ETH_SEND, 
ETH_RECEIVE, or BLOCK_SEND hypercalls.


-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/