[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZcGo8yr5oYV6Cf2K@google.com>
Date: Mon, 5 Feb 2024 19:35:15 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Yan Zhao <yan.y.zhao@...el.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Kai Huang <kai.huang@...el.com>, Yuan Yao <yuan.yao@...ux.intel.com>,
Xu Yilun <yilun.xu@...ux.intel.com>
Subject: Re: [PATCH v3] KVM: x86/mmu: Retry fault before acquiring mmu_lock if
mapping is changing
On Tue, Feb 06, 2024, Yan Zhao wrote:
> > Just to be super claer, by "repeated faulting", you mean repeated faulting in the
> > primary MMU, correct?
> >
> Yes. Faulting in the primary MMU.
> (Please ignore my typo in return type above :))
>
> BTW, will you also send the optmization in v1 as below?
No, mainly because I'm not entirely confident that it's safe/correct to loop
there, at least not that "tightly". At the very least, there would need to be
resched checks, and then probably signal checks, etc.
I'm not opposed to something of this nature if it provides a measurable benefit
to the guest, but it's firmly an "on top" sort of change.
> iff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 1e340098d034..c7617991e290 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -5725,11 +5725,13 @@ int noinline kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 err
> }
>
> if (r == RET_PF_INVALID) {
> - r = kvm_mmu_do_page_fault(vcpu, cr2_or_gpa,
> - lower_32_bits(error_code), false,
> - &emulation_type);
> - if (KVM_BUG_ON(r == RET_PF_INVALID, vcpu->kvm))
> - return -EIO;
> + do {
> + r = kvm_mmu_do_page_fault(vcpu, cr2_or_gpa,
> + lower_32_bits(error_code),
> + false, &emulation_type);
> + if (KVM_BUG_ON(r == RET_PF_INVALID, vcpu->kvm))
> + return -EIO;
> + while (r == RET_PF_RETRY);
> }
>
> if (r < 0)
Powered by blists - more mailing lists