On 11/9/24 22:11, Doug Covelli wrote:
On Sat, Nov 9, 2024 at 1:20 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> 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/739c5a2f4bfd4cdda491e6a6f6869d88c0bd6972/open-vm-tools/lib/include/backdoor_def.h#L97
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_PAT
and 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_STEALCLOCK
I'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
