From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oupton@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>,
Quentin Perret <qperret@google.com>,
Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH 3/6] KVM: arm64: Make stage2_pte_cacheable() return false when S2_AS_S1 is set
Date: Fri, 23 Jan 2026 13:21:24 +0000 [thread overview]
Message-ID: <86ldhobh2j.wl-maz@kernel.org> (raw)
In-Reply-To: <aXI8cchH7l1SHbQR@willie-the-truck>
On Thu, 22 Jan 2026 15:04:17 +0000,
Will Deacon <will@kernel.org> wrote:
>
> On Mon, Jan 19, 2026 at 10:56:48AM +0000, Marc Zyngier wrote:
> > We cannot tell from the S2 attributes whether what we map is memory
> > or not when S2_AS_S1 is set, and issuing a CMO on device memory may
> > not be the best idea.
> >
> > In this particular case, pretend that the mapping isn't cacheable.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/hyp/pgtable.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 3c5f399b1b986..07561a227f75e 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > @@ -911,6 +911,14 @@ static void stage2_unmap_put_pte(const struct kvm_pgtable_visit_ctx *ctx,
> > static bool stage2_pte_cacheable(struct kvm_pgtable *pgt, kvm_pte_t pte)
> > {
> > u64 memattr = pte & KVM_PTE_LEAF_ATTR_LO_S2_MEMATTR;
> > +
> > + /*
> > + * With S2_AS_S1, we have no idea whether the OA is actual memory or
> > + * a device. Don't even try a CMO on that.
> > + */
> > + if (pgt->flags & KVM_PGTABLE_S2_AS_S1)
> > + return false;
> > +
> > return kvm_pte_valid(pte) && memattr == KVM_S2_MEMATTR(pgt, NORMAL);
>
> Since KVM_PGTABLE_S2_AS_S1 is only set for the pKVM host stage-2 and
> that doesn't provide any cache maintenance callbacks in its
> kvm_pgtable_mm_ops, I don't think the current code is actually broken,
Frankly, I have no idea how I came to such a stupid conclusion. My
only way out is to blame Metallica (don't listen to that shit, kids!).
> although it's harmless to add the check (and the comment might benefit
> from some additional rewording?).
I don't think there is much value in adding something that is not
useful. I'll drop that patch altogether.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-01-23 13:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 10:56 [PATCH 0/6] KVM: arm64: ... and FWB for all Marc Zyngier
2026-01-19 10:56 ` [PATCH 1/6] arm64: Add MT_S2{,_FWB}_AS_S1 encodings Marc Zyngier
2026-01-22 15:07 ` Fuad Tabba
2026-01-19 10:56 ` [PATCH 2/6] KVM: arm64: Add KVM_PGTABLE_S2_AS_S1 flag Marc Zyngier
2026-01-22 15:08 ` Fuad Tabba
2026-01-22 17:05 ` Will Deacon
2026-01-19 10:56 ` [PATCH 3/6] KVM: arm64: Make stage2_pte_cacheable() return false when S2_AS_S1 is set Marc Zyngier
2026-01-22 15:04 ` Will Deacon
2026-01-23 13:21 ` Marc Zyngier [this message]
2026-01-19 10:56 ` [PATCH 4/6] KVM: arm64: Switch pKVM host S2 over to KVM_PGTABLE_S2_AS_S1 Marc Zyngier
2026-01-22 15:09 ` Fuad Tabba
2026-01-19 10:56 ` [PATCH 5/6] KVM: arm64: Kill KVM_PGTABLE_S2_NOFWB Marc Zyngier
2026-01-22 15:09 ` Fuad Tabba
2026-01-19 10:56 ` [PATCH 6/6] KVM: arm64: Simplify PAGE_S2_MEMATTR Marc Zyngier
2026-01-22 15:03 ` Will Deacon
2026-01-21 16:23 ` [PATCH 0/6] KVM: arm64: ... and FWB for all Joey Gouly
2026-01-21 18:13 ` Fuad Tabba
2026-01-23 12:22 ` Alexandru Elisei
2026-01-23 12:37 ` Marc Zyngier
2026-01-23 15:17 ` Alexandru Elisei
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=86ldhobh2j.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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.