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:26 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.