On Thu, 2022-04-21 at 08:12 +0300, Maxim Levitsky wrote:
> ---
> arch/x86/kvm/mmu/mmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 23f895d439cf5..b63398dfdac3b 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -5315,8 +5315,8 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t
> cr2_or_gpa, u64 error_code,
> */
> if (vcpu->arch.mmu->root_role.direct &&
> (error_code & PFERR_NESTED_GUEST_PAGE) == PFERR_NESTED_GUEST_PAGE) {
> - kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2_or_gpa));
> - return 1;
> + if (kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2_or_gpa)))
> + return 1;
> }
>
> /*
I forgot to add commit description here:
If non leaf mmu page is write tracked externally for some reason,
which can in theory happen if it was used for nested avic physid page
before, then this code will enter an endless loop of page faults because
unprotecting the page will not remove write tracking, nor will the
write tracker callback be called.
Fix this by only invoking the fast patch if we succeeded in zapping the
mmu page.
Fixes: 147277540bbc5 ("kvm: svm: Add support for additional SVM NPF error
codes")
Signed-off-by: Maxim Levitsky <mlevi...@redhat.com>
--
In theory, KVMGT also does external write tracking so in theory this issue can
happen today,
but it is highly unlikely.
Best regards,
Maxim Levitsk
