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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
