Re: "KVM: x86/mmu: Overhaul TDP MMU zapping and flushing" breaks SVM on Hyper-V

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/13/23 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.

My reading of the spec[1] is that HV_X64_NESTED_ENLIGHTENED_TLB will cause svm_flush_tlb_current to behave (in Intel parlance) as an INVVPID rather than an INVEPT. So svm_flush_tlb_current has to be changed to also add a call to HvCallFlushGuestPhysicalAddressSpace. I'm not sure if that's a good idea though.

First, that's a TLB shootdown rather than just a local thing; flush_tlb_current is supposed to be relatively cheap, and there would be a lot of them because of the unconditional calls to nested_svm_transition_tlb_flush on vmentry/vmexit.

Second, while the nCR3 matches across virtual processors for SVM, the (nCR3, ASID) pair does not, so it doesn't even make much sense to do a TLB shootdown.

Depending on the performance results of adding the hypercall to svm_flush_tlb_current, the fix could indeed be to just disable usage of HV_X64_NESTED_ENLIGHTENED_TLB.

Paolo

[1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/nested-virtualization




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux