On 11/9/24 22:11, Doug Covelli wrote:
On Sat, Nov 9, 2024 at 1:20 PM Paolo Bonzini pbonzini@redhat.com wrote:
On 11/8/24 06:03, Zack Rusin wrote:
There's no spec but we have open headers listing the hypercalls. There's about a 100 of them (a few were deprecated), the full list starts here: https://github.com/vmware/open-vm-tools/blob/739c5a2f4bfd4cdda491e6a6f6869d8... They're not well documented, but the names are pretty self-explenatory.
At a quick glance, this one needs to be handled in KVM:
BDOOR_CMD_VCPU_MMIO_HONORS_PATand these probably should be in KVM:
BDOOR_CMD_GETTIME BDOOR_CMD_SIDT BDOOR_CMD_SGDT BDOOR_CMD_SLDT_STR BDOOR_CMD_GETTIMEFULL BDOOR_CMD_VCPU_LEGACY_X2APIC_OK BDOOR_CMD_STEALCLOCKI'm not sure if there's any value in implementing a few of them.
The value is that some of these depend on what the hypervisor does, not on what userspace does. For Hypervisor.framework you have a lot of leeway, for KVM and Hyper-V less so. [..] From the KVM maintainers' point of view, the feature you're adding might be used by others and not just VMware Workstation. Microsoft and Apple might see things differently (Apple in particular has a much thinner wrapper around the processor's virtualization capbilities).
[...]
the SGDT/SLDT/STR/SIDT backdoor calls these were added > 20 years ago for SW that used these instructions from CPL3 which did not work well before VT/SVM were introduced. These are really of no use on modern CPUs and will be blocked if the guest OS has enabled UMIP. [...]
For stolen time the backdoor call is [...] currently really only supported by ESX (and only currently used by Photon OS) so I don't think adding that support to KVM is critical.
Sounds good. All I want is ensuring that someone with access to the spec did the exercise.
Still guessing, but for MMIO_HONORS_PAT we probably want to add a separate KVM_CHECK_EXTENSION capability.
Is BDOOR_CMD_VCPU_LEGACY_X2APIC_OK something where you can just return a constant?
This leaves just GETTIME and GETTIMEFULL. If four hypercalls require some care in the hypervisor (which may or may not be an in-kernel implementation), that's not bad. Can you share a bit more about these four?
Anyway, one question apart from this: is the API the same for the I/O port and hypercall backdoors?
Yeah the calls and arguments are the same. The hypercall based interface is an attempt to modernize the backdoor since as you pointed out the I/O based interface is kind of hacky as it bypasses the normal checks for an I/O port access at CPL3. It would be nice to get rid of it but unfortunately I don't think that will happen in the foreseeable future as there are a lot of existing VMs out there with older SW that still uses this interface.
Yeah, but I think it still justifies that the KVM_ENABLE_CAP API can enable the hypercall but not the I/O port.
Paolo