Re: [PATCH 2/3] KVM: x86: Add support for VMware guest specific hypercalls

[Paolo Bonzini <pbonzini@redhat.com>]

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/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