On 13/02/2023 18:38, Sean Christopherson wrote: > 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. > I couldn't reproduce this in any way on Intel. I can test again tomorrow, and see what the differences are in the ftrace. >> 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).
