From: Dan Carpenter <dan@pereq.eu>
To: Marc Zyngier <maz@kernel.org>
Cc: "Dan Carpenter" <dan@cryspen.com>,
"Oliver Upton" <oupton@kernel.org>,
"Fuad Tabba" <fuad.tabba@linux.dev>,
"Joey Gouly" <joey.gouly@arm.com>,
"Steffen Eiden" <seiden@linux.ibm.com>,
"Suzuki K Poulose" <suzuki.poulose@arm.com>,
"Zenghui Yu" <yuzenghui@huawei.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org,
"Karthik Bhargavan" <karthik@pereq.eu>,
"Clément Blaudeau" <clement@cryspen.com>
Subject: Re: [PATCH] KVM: arm64: nv: Initialize hw_mmu to NULL for nested vCPUs
Date: Thu, 12 Nov 2026 08:28:42 +0300 [thread overview]
Message-ID: <avVOivX0YmlES4Pe@stanley.mountain> (raw)
In-Reply-To: <86ld6z1782.wl-maz@kernel.org>
On Wed, Nov 11, 2026 at 07:46:53PM +0000, Marc Zyngier wrote:
>
> I think this really needs a comment to explain why we repaint hw_mmu
> to NULL, because the next idiot who looks at this (likely me) will
> probably remove this line...
>
> The other thing is that this means that nothing can evaluate
> vcpu->arch.hw_mmu anywhere outside of the loaded path, as it can be
> NULL. I *think* this is OK, but I need to really convince myself...
>
> I'd like to add something like:
>
> /*
> * We can't rely on the S2 MMU being the canonical one,
> * as userspace can restore a nested context. Nuke the
> * hw_mmu early to ensure that we pick the correct one
> * load time. It also means that we can't rely on hw_mmu
> * being set to anything useful if the vcpu isn't loaded.
> */
>
> If that works for you, I'll squash that in.
Absolutely. Thanks so much.
regards,
dan carpenter
prev parent reply other threads:[~2026-11-12 5:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 11:11 [PATCH] KVM: arm64: nv: Initialize hw_mmu to NULL for nested vCPUs Dan Carpenter
2026-11-11 19:46 ` Marc Zyngier
2026-11-12 5:28 ` Dan Carpenter [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=avVOivX0YmlES4Pe@stanley.mountain \
--to=dan@pereq.eu \
--cc=catalin.marinas@arm.com \
--cc=clement@cryspen.com \
--cc=dan@cryspen.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=karthik@pereq.eu \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--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.