Re: [RFC PATCH 1/3] add generic hypercall support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gregory Haskins wrote:
We add a generic hypercall() mechanism for use by IO code which is
compatible with a variety of hypervisors, but which prefers to use
hypercalls over other types of hypervisor traps for performance and/or
feature reasons.

For instance, consider an emulated PCI device in KVM.  Today we can chose
to do IO over MMIO or PIO infrastructure, but they each have their own
distinct disadvantages:

*) MMIO causes a page-fault, which must be decoded by the hypervisor and is
   therefore fairly expensive.

*) PIO is more direct than MMIO, but it poses other problems such as:
      a) can have a small limited address space (x86 is 2^16)
      b) is a narrow-band interface (one 8, 16, 32, 64 bit word at a time)
      c) not available on all archs (PCI mentions ppc as problematic) and
         is therefore recommended to avoid.

Hypercalls, on the other hand, offer a direct access path like PIOs, yet
do not suffer the same drawbacks such as a limited address space or a
narrow-band interface.  Hypercalls are much more friendly to software
to software interaction since we can pack multiple registers in a way
that is natural and simple for software to utilize.

No way. Hypercalls are just about awful because they cannot be implemented sanely with VT/SVM as Intel/AMD couldn't agree on a common instruction for it. This means you either need a hypercall page, which I'm pretty sure makes transparent migration impossible, or you need to do hypercall patching which is going to throw off attestation.

If anything, I'd argue that we shouldn't use hypercalls for anything in KVM because it will break run-time attestation.

Hypercalls cannot pass any data either. We pass data with hypercalls by relying on external state (like register state). It's just as easy to do this with PIO. VMware does this with vmport, for instance. However, in general, you do not want to pass that much data with a notification. It's better to rely on some external state (like a ring queue) and have the "hypercall" act simply as a notification mechanism.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux