On Wed Nov 8, 2023 at 12:49 PM UTC, Alexander Graf wrote: > > On 08.11.23 12:18, Nicolas Saenz Julienne wrote: > > Introduce HVCALL_TRANSLATE_VIRTUAL_ADDRESS, the hypercall receives a > > GVA, generally from a less privileged VTL, and returns the GPA backing > > it. The GVA -> GPA conversion is done by walking the target VTL's vCPU > > MMU. > > > > NOTE: The hypercall implementation is incomplete and only shared for > > completion. Additionally we'd like to move the VTL aware parts to > > user-space. > > > Yes, please :). We should handle the complete hypercall in user space if > possible. If you're afraid that gva -> gpa conversion may run out of > sync between a user space and the kvm implementations, let's introduce > an ioctl that allows you to perform that conversion. I'll look into introducing a generic API that performs MMU walks. The devil is in the details though, the hypercall introduces flags like: • HV_TRANSLATE_GVA_TLB_FLUSH_INHIBIT: Indicates that the TlbFlushInhibit flag in the virtual processor’s HvRegisterInterceptSuspend register should be set as a consequence of a successful return. This prevents other virtual processors associated with the target partition from flushing the stage 1 TLB of the specified virtual processor until after the TlbFlushInhibit flag is cleared. Which make things trickier. Nicolas
