Re: [PATCH v2 21/29] KVM: nSVM: Handle nested TLB flush requests through TLB_CONTROL

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kvm: nSVM: Failure to clear vmcb12->control.tlb_ctl on nested VMRUN causes sticky flushes
--

commit a1eb425c937534a8aa46b2b08b4187a40adeac38
Author: Yosry Ahmed <yosry@kernel.org>
Subject: KVM: nSVM: Handle nested TLB flush requests through TLB_CONTROL

This commit handles L1 requests to flush L2 TLBs using the TLB_CONTROL
field of VMCB12. It triggers ASID flushes and NPT syncs on nested VM-Enter
or VM-Exit depending on the type of flush requested.

[Severity: High]
According to the AMD APM Volume 2, Section 15.15.1, the VMRUN instruction
processes the TLB_CONTROL field of the VMCB and then clears it to zero.

Looking at the implementation in arch/x86/kvm/svm/nested.c, specifically
within nested_svm_entry_tlb_flush() at line 710, the new logic requests
KVM_REQ_MMU_SYNC_ALL_ROOTS and KVM_REQ_TLB_FLUSH_GUEST whenever
svm->nested.ctl.tlb_ctl is not TLB_CONTROL_DO_NOTHING.

However, it appears KVM never clears tlb_ctl to 0 in vmcb12 during the
nested entry sequence, nor during VM-Exit in
nested_svm_vmexit_update_vmcb12() at line 1582 where other
hardware-cleared fields like event_inj are reset.

Because KVM fails to emulate the hardware behavior of clearing the field,
will L1 hypervisors that rely on hardware to clear it unknowingly reuse
vmcb12 with tlb_ctl permanently stuck at a non-zero value?

If so, does this introduce a regression that traps the VM in a persistent
loop of heavy MMU root syncs and TLB flushes on every single subsequent
VMRUN, resulting in severe performance degradation for the nested VM?

Could we add a step to clear tlb_ctl in vmcb12 to prevent these sticky
flushes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008001425.2458927-1-yosry@kernel.org?part=21