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

[Doug Covelli]

On Tue, Jan 7, 2025 at 12:10 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On Wed, Dec 18, 2024 at 4:44 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > Changing our legacy BIOS is not an option so in order to support Windows VMs
> > > with the legacy BIOS with decent performance we would either need to add support
> > > for remote reads of the APIC ID register to KVM or support CR8 accesses w/o
> > > exiting w/o the in-kernel APIC in order.  Do you have a preference?
> >
> > I didn't quite follow the CR8 access thing.  If the choice is between emulating
> > Remote Read IPIs and using a userspace local APIC, then I vote with both hands
> > for emulating Remote Reads, especially if we can do a half-assed version that
> > provides only what your crazy BIOS needs :-)
>
> Absolutely.  Not quite userspace local APIC - VMware only needs
> userspace traps on CR8 access but yeah, it would not be great to have
> that. Remote read support is totally acceptable and hopefully win-win
> for VMware too.
>
> > The biggest wrinkle I can think of is that KVM uses the Remote Read IPI encoding
> > for a paravirt vCPU kick feature, but I doubt that's used by Windows guests and
> > so can be sacrificed on the Altar of Ancient BIOS.
>
> That's easy, the existing code can be wrapped with
>
>                 if (guest_pv_has(vcpu, KVM_FEATURE_PV_UNHALT))
>
> The remote-read hack is not even supposed to be used by the guest
> (it's used internally by kvm_pv_kick_cpu_op).
>
> Paolo

OK.  It seems like fully embracing the in-kernel APIC is the way to go
especially considering it really simplifies using KVM's support for nested
virtualization.  Speaking of nested virtualization we have been working on
adding support for that and would like to propose a couple of changes:

- Add an option for L0 to handle backdoor accesses from CPL3 code running in L2.
On a #GP nested_vmx_l0_wants_exit can check if this option is enabled and KVM
can handle the #GP like it would if it had been from L1 (exit to userlevel iff
it is a backdoor access otherwwise deliver the fault to L2).  When combined with
enable_vmware_backdoor this will allow L0 to optionally handle backdoor accesses
from CPL3 code running in L2.  This is needed for cases such as running VMware
tools in a Windows VM with VBS enabled.  For other cases such as running tools
in a Windows VM in an ESX VM we still want L1 to handle the backdoor accesses
from L2.

- Extend KVM_EXIT_MEMORY_FAULT for permission faults (e.g the guest attempting
to write to a page that has been protected by userlevel calling mprotect).  This
is useful for cases where we want synchronous detection of guest writes such as
lazy snapshots (dirty page tracking is no good for this case).  Currently
permission faults result in KVM_RUN returning EFAULT which we handle by
interpreting the instruction as we do not know the guest physical address
associated with the fault.  This works fine for normal VMs but it would be good
to avoid it for the case where nested virtualization is enabled as emulating L2
instructions presents a number of challenges and it would be best to avoid this.
This is the only case I have found where our userlevel code has to interpret
instructions from L2.

Any thoughts on these proposed changes?

Doug

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.