On 2/24/23 17:17, Jeremi Piotrowski wrote:
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.
Minus making nested SVM (L3) mutually exclusive, I believe this will do the trick:
+ /* blah blah blah */
+ hv_flush_tlb_current(vcpu);
+
Yes, it's either this or disabling the feature.
Paolo
Combining the two sub-threads: both of the suggestions:
a) adding a hyperv_flush_guest_mapping(__pa(root->spt) after kvm_tdp_mmu_get_vcpu_root_hpa's call to tdp_mmu_alloc_sp()
b) adding a hyperv_flush_guest_mapping(vcpu->arch.mmu->root.hpa) to svm_flush_tlb_current()
appear to work in my test case (L2 vm startup until panic due to missing rootfs).
But in both these cases (and also when I completely disable HV_X64_NESTED_ENLIGHTENED_TLB)
the runtime of an iteration of the test is noticeably longer compared to tdp_mmu=0.
Hmm, what is test doing?
Booting through OVMF and kernel with no rootfs provided, and panic=-1 specified on the
kernel command line. It's a pure startup time test.
Hi Sean,
Have you been able to reproduce this by any chance?
I would be glad to see either of the two fixes getting merged (b) or a) if it doesn't require
special L3 nested handling) in order to get this regression resolved.
For now the easiest course of action is to just disable the TDP MMU if
HV_X64_NESTED_ENLIGHTENED_TLB is available.
Paolo
