On Fri, Oct 04, 2024, Nikolas Wipper wrote: > This series introduces a new ioctl KVM_HYPERV_SET_TLB_FLUSH_INHIBIT. It > allows hypervisors to inhibit remote TLB flushing of a vCPU coming from > Hyper-V hyper-calls (namely HvFlushVirtualAddressSpace(Ex) and > HvFlushirtualAddressList(Ex)). It is required to implement the > HvTranslateVirtualAddress hyper-call as part of the ongoing effort to > emulate VSM within KVM and QEMU. The hyper-call requires several new KVM > APIs, one of which is KVM_HYPERV_SET_TLB_FLUSH_INHIBIT. > > Once the inhibit flag is set, any processor attempting to flush the TLB on > the marked vCPU, with a HyperV hyper-call, will be suspended until the > flag is cleared again. During the suspension the vCPU will not run at all, > neither receiving events nor running other code. It will wake up from > suspension once the vCPU it is waiting on clears the inhibit flag. This > behaviour is specified in Microsoft's "Hypervisor Top Level Functional > Specification" (TLFS). > > The vCPU will block execution during the suspension, making it transparent > to the hypervisor. s/hypervisor/VMM. In the world of KVM, the typical terminology is that KVM itself is the hypervisor, and the userspace side is the VMM. It's not perfect, but it's good enough and fairly ubiquitous at this point, and thus many readers will be quite confused as to how a vCPU blocking is transparent to KVM :-)
