Userspace hypercalls?

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

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.

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?

Regards,

Anthony Liguori


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