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