Re: Userspace hypercalls?

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

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.

-- 
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/