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.
next prev parent 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