On Fri, Feb 10, 2023, Jeremi Piotrowski wrote: > Hi Paolo/Sean, > > We've noticed that changes introduced in "KVM: x86/mmu: Overhaul TDP MMU > zapping and flushing" conflict with a nested Hyper-V enlightenment that is > always enabled on AMD CPUs (HV_X64_NESTED_ENLIGHTENED_TLB). The scenario that > is affected is L0 Hyper-V + L1 KVM on AMD, Do you see issues with Intel and HV_X64_NESTED_GUEST_MAPPING_FLUSH? IIUC, on the KVM side, that setup is equivalent to HV_X64_NESTED_ENLIGHTENED_TLB. > IIRC, KVM side always uses write-protected translation table to shadow and so > doesn't meet such issue with the commit. This is incorrect. KVM write-protects guest PTEs that point at 2MiB and larger pages, but 4KiB PTEs are allowed to become "unsync" and KVM's shadow NPT/EPT entries are synchronized with the guest only on a relevant TLB. I know of at least one non-KVM-hypervisor TDP TLB flushing bug that was found specifically because of KVM's infinite software TLB. That doesn't mean that this isn't a KVM bug, I just want to call out that KVM-on-KVM should be capable of detecting KVM-as-L1 TLB bugs, at least on Intel/VMX/EPT (KVM's nested SVM support is woefully naive from a TLB flushing perspective and synchronizes guest PTEs before every nested VM-Entry to L2).
