Re: [RFC PATCH 0/3] generic hypercall support

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

 



Avi Kivity wrote:
Anthony Liguori wrote:

It's a question of cost vs. benefit. It's clear the benefit is low (but that doesn't mean it's not worth having). The cost initially appeared to be very low, until the nested virtualization wrench was thrown into the works. Not that nested virtualization is a reality -- even on svm where it is implemented it is not yet production quality and is disabled by default.

Now nested virtualization is beginning to look interesting, with Windows 7's XP mode requiring virtualization extensions. Desktop virtualization is also something likely to use device assignment (though you probably won't assign a virtio device to the XP instance inside Windows 7).

Maybe we should revisit the mmio hypercall idea again, it might be workable if we find a way to let the guest know if it should use the hypercall or not for a given memory range.

mmio hypercall is nice because
- it falls back nicely to pure mmio
- it optimizes an existing slow path, not just new device models
- it has preexisting semantics, so we have less ABI to screw up
- for nested virtualization + device assignment, we can drop it and get a nice speed win (or rather, less speed loss)

If it's a PCI device, then we can also have an interrupt which we currently lack with vmcall-based hypercalls. This would give us guestcalls, upcalls, or whatever we've previously decided to call them.

Sorry, I totally failed to understand this.  Please explain.

I totally missed what you meant by MMIO hypercall.

In what cases do you think MMIO hypercall would result in a net benefit?

I think the difference in MMIO vs hcall will be overshadowed by the heavy weight transition to userspace. The only thing I can think of where it may matter is for in-kernel devices like the APIC but that's a totally different path in Linux.

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