From: Vincent Donnefort <vdonnefort@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: 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
Subject: Re: [PATCH v2] KVM: arm64: Fix protected VM fault on system with pages larger than 4K
Date: Mon, 14 Sep 2026 09:41:46 +0100 [thread overview]
Message-ID: <aqezSgNz55DzInH0@google.com> (raw)
In-Reply-To: <864ifs6xn4.wl-maz@kernel.org>
On Mon, Sep 14, 2026 at 09:32:47AM +0100, Marc Zyngier wrote:
> On Mon, 14 Sep 2026 08:58:39 +0100,
> Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > Just like commit 08f97454b7fa ("KVM: arm64: Fix protected mode handling
> > of pages larger than 4kB") fixed the boot of non-protected VMs on system
> > larger than 4K pages, align the fault IPA down to the page-size for
> > protected VMs.
> >
> > To paraphrase Marc, pkvm_pgtable_stage2_map() assumes the address passed
> > as a parameter is aligned to the size of the intended mapping, while
> > HPFAR_EL2 gives the IPA minus the bottom 12 bits, regardless of the
> > system page size configuration.
> >
> > Add a check at the start of pkvm_pgtable_stage2_map() as we do not
> > support !PAGE_ALIGNED arguments and use the gfn as an argument in all
> > callers.
> >
> > Fixes: ea03466e806f ("KVM: arm64: Handle aborts from protected VMs")
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> > ---
> >
> > Changelog:
> >
> > v2:
> > - Use gfn_to_gpa(gfn)
> > - Drop "phys" from the PAGE_ALIGNED check, it isn't a requirement.
> > - Fix gmem_abort() as well (Sashiko)
> >
> > v1: https://lore.kernel.org/all/20260913173516.3122436-1-vdonnefort@google.com/
> >
> > arch/arm64/kvm/mmu.c | 7 ++++---
> > arch/arm64/kvm/pkvm.c | 3 +++
> > 2 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 9ba86450fe4a..ee78201a44df 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -1672,10 +1672,10 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> > * PTE, which will be preserved.
> > */
>
> Context:
>
> if (s2fd->nested)
> gfn = kvm_s2_trans_output(s2fd->nested) >> PAGE_SHIFT;
> else
> gfn = s2fd->fault_ipa >> PAGE_SHIFT;
>
> [...]
>
> > prot &= ~KVM_NV_GUEST_MAP_SZ;
> > - ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, s2fd->fault_ipa,
> > + ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, gfn_to_gpa(gfn),
> > prot, flags);
> > } else {
> > - ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
> > + ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, gfn_to_gpa(gfn), PAGE_SIZE,
> > __pfn_to_phys(pfn), prot,
> > memcache, flags);
>
> So 'gfn' is not related to the faulting IPA in the nested case, but is
> the output address of the guest's own S2. You probably end-up with a
> livelock handling the same fault forever, or worse.
>
> It is a bit annoying that neither gmem nor pkvm are using
> kvm_s2_fault_vma_info, which has the ability to reports all the
> important stuff, as it would avoid this sort of bugs.
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Using kvm_s2_fault_vma_info would surely help the THP support for protected VMs
[1]. I am thinking now about bringing it as part of that series.
However for a fix, that's a bit much?
[1] https://lore.kernel.org/all/20260911135053.146435-23-vdonnefort@google.com/
--
Vincent
prev parent reply other threads:[~2026-09-14 8:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 7:58 [PATCH v2] KVM: arm64: Fix protected VM fault on system with pages larger than 4K Vincent Donnefort
2026-09-14 8:13 ` sashiko-bot
2026-09-14 8:19 ` Vincent Donnefort
2026-09-14 8:32 ` Marc Zyngier
2026-09-14 8:40 ` Fuad Tabba
2026-09-14 8:41 ` Vincent Donnefort [this message]
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=aqezSgNz55DzInH0@google.com \
--to=vdonnefort@google.com \
--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=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@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.