Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Wei-Lin Chang <weilin.chang@arm.com>
Cc: Vincent Donnefort <vdonnefort@google.com>,
	oupton@kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com,
	seiden@linux.ibm.com, suzuki.poulose@arm.com,
	yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
	kernel-team@android.com, fuad.tabba@linux.dev,
	qperret@google.com, Sashiko <sashiko-bot@kernel.org>,
	stable@vger.kernel.org
Subject: Re: [PATCH v1 5/6] KVM: arm64: Use kvm_s2_fault_vma_info in gmem_abort()
Date: Sun, 27 Sep 2026 17:30:04 +0100	[thread overview]
Message-ID: <87qzie3beb.wl-maz@kernel.org> (raw)
In-Reply-To: <am2rfnuwjkglavbtzkt2lk2gclahvca5irrv5me4vppzkotexf@yauajpybhsnm>

On Fri, 25 Sep 2026 18:36:42 +0100,
Wei-Lin Chang <weilin.chang@arm.com> wrote:
> 
> On Tue, Sep 22, 2026 at 02:08:20PM +0100, Vincent Donnefort wrote:
> > From: Fuad Tabba <fuad.tabba@linux.dev>
> > 
> > gmem_abort() maps at s2fd->fault_ipa, which HPFAR_EL2 holds at 4K
> > granularity whatever the page size. The generic page-table code aligns
> > it, but pkvm_pgtable_stage2_map() looks up existing mappings over
> > [addr, addr + size), so on a pKVM host with pages larger than 4K a
> > guest_memfd-backed guest that faults past the first 4K of a page can
> > find its neighbour's mapping, get -EAGAIN and take the same fault
> > forever.
> > 
> > Take the addresses from kvm_s2_fault_vma_info instead, as
> > user_mem_abort() does, and report the gfn kvm_gmem_get_pfn() failed on
> > in the memory fault exit. kvm_s2_fault_get_vma_info() itself isn't
> > called: a guest_memfd memslot's userspace_addr doesn't need to be
> > backed by a VMA.
> > 
> > Fixes: a7b57e0995927 ("KVM: arm64: Handle guest_memfd-backed guest page faults")
> > Reported-by: Sashiko <sashiko-bot@kernel.org>
> > Closes: https://lore.kernel.org/r/20260913175105.A57AC1F000FF@smtp.kernel.org
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> > ---
> >  arch/arm64/kvm/mmu.c | 28 +++++++++++++---------------
> >  1 file changed, 13 insertions(+), 15 deletions(-)
> > 
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 5aac624b0442..ee0fcca838c1 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1953,11 +1953,9 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> >  	enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
> >  	enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
> >  	struct kvm_pgtable *pgt = s2fd->vcpu->arch.hw_mmu->pgt;
> > -	unsigned long mmu_seq;
> > -	struct page *page;
> > +	struct kvm_s2_fault_vma_info s2vi = {};
> 
> I'd say it's unfortunate this struct's name contains vma :P

If that was the only thing that is wrong in the MMU code, we'd be in a
pretty good position! ;-)

> 
> >  	struct kvm *kvm = s2fd->vcpu->kvm;
> >  	void *memcache = NULL;
> > -	kvm_pfn_t pfn;
> >  	gfn_t gfn;
> >  	int ret;
> >  
> > @@ -1968,23 +1966,22 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> >  			return ret;
> >  	}
> >  
> > -	if (s2fd->nested)
> > -		gfn = kvm_s2_trans_output(s2fd->nested) >> PAGE_SHIFT;
> > -	else
> > -		gfn = s2fd->fault_ipa >> PAGE_SHIFT;
> > +	s2vi.vma_pagesize = PAGE_SIZE;
> > +	s2vi.gfn = ALIGN_DOWN(s2fd->fault_ipa, s2vi.vma_pagesize) >> PAGE_SHIFT;
> > +	gfn = get_canonical_gfn(s2fd, &s2vi);
> 
> Perhaps it is worth reserving plain "gfn" for the value we use as the
> IA of the (shadow) page table, and name this variable something like
> canonical_gfn. Similar to what kvm_s2_fault_map() does.

Maybe. We have gfn in the vncr fault handling code as well, but that
one is the result of a S1 walk, so maybe more obvious.

> 
> >  
> >  	write_fault = kvm_is_write_fault(s2fd->vcpu);
> >  	exec_fault = kvm_vcpu_trap_is_exec_fault(s2fd->vcpu);
> >  
> >  	VM_WARN_ON_ONCE(write_fault && exec_fault);
> >  
> > -	mmu_seq = kvm->mmu_invalidate_seq;
> > +	s2vi.mmu_seq = kvm->mmu_invalidate_seq;
> >  	/* Pairs with the smp_wmb() in kvm_mmu_invalidate_end(). */
> >  	smp_rmb();
> >  
> > -	ret = kvm_gmem_get_pfn(kvm, s2fd->memslot, gfn, &pfn, &page, NULL);
> > +	ret = kvm_gmem_get_pfn(kvm, s2fd->memslot, gfn, &s2vi.pfn, &s2vi.page, NULL);
> >  	if (ret) {
> > -		kvm_prepare_memory_fault_exit(s2fd->vcpu, s2fd->fault_ipa, PAGE_SIZE,
> > +		kvm_prepare_memory_fault_exit(s2fd->vcpu, gfn_to_gpa(gfn), s2vi.vma_pagesize,
> 
> Huh, I guess you also fixed a bug here? s2fd->fault_ipa could be the
> nested ipa instead of the canonical ipa.

Yeah, it appears so. Worth capturing in Fixes: as well.

	M.

-- 
Jazz isn't dead. It just smells funny.


  reply	other threads:[~2026-09-27 16:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 13:08 [PATCH v1 0/6] Fix guest_memfd and protected VMs on systems with pages larger than 4K Vincent Donnefort
2026-09-22 13:08 ` [PATCH v1 1/6] KVM: arm64: Fix MMFR0 TGRAN advertisement for pVMs Vincent Donnefort
2026-09-22 13:08 ` [PATCH v1 2/6] KVM: arm64: Pass kvm_s2_fault_desc to fault_supports_stage2_huge_mapping() Vincent Donnefort
2026-09-23 19:33   ` Fuad Tabba
2026-09-25 17:46   ` Wei-Lin Chang
2026-09-22 13:08 ` [PATCH v1 3/6] KVM: arm64: Move pkvm_mem_abort() Vincent Donnefort
2026-09-23 19:38   ` Fuad Tabba
2026-09-27 16:31   ` Marc Zyngier
2026-09-22 13:08 ` [PATCH v1 4/6] KVM: arm64: Move gmem_abort() Vincent Donnefort
2026-09-22 13:08 ` [PATCH v1 5/6] KVM: arm64: Use kvm_s2_fault_vma_info in gmem_abort() Vincent Donnefort
2026-09-25 17:36   ` Wei-Lin Chang
2026-09-27 16:30     ` Marc Zyngier [this message]
2026-09-28  7:44       ` Fuad Tabba
2026-09-22 13:08 ` [PATCH v1 6/6] KVM: arm64: Use kvm_s2_fault_vma_info in pkvm_mem_abort() Vincent Donnefort
2026-09-23 19:39   ` Fuad Tabba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87qzie3beb.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=fuad.tabba@linux.dev \
    --cc=joey.gouly@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oupton@kernel.org \
    --cc=qperret@google.com \
    --cc=sashiko-bot@kernel.org \
    --cc=seiden@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=vdonnefort@google.com \
    --cc=weilin.chang@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox