All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Dan Carpenter <dan@cryspen.com>
Cc: "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: Wed, 11 Nov 2026 19:46:53 +0000	[thread overview]
Message-ID: <86ld6z1782.wl-maz@kernel.org> (raw)
In-Reply-To: <d3571fb535e1832d2a067649f294b83d824d4350.1794395321.git.dan@cryspen.com>

Hi Dan,

On Wed, 11 Nov 2026 11:11:19 +0000,
Dan Carpenter <dan@cryspen.com> wrote:
> 
> Before commit 6ded46b5a4fd ("KVM: arm64: nv: Keep reference on stage-2
> MMU when scheduled out"), kvm_vcpu_load_hw_mmu() would set ->hw_mmu on
> every load.  Now it only sets it when it is set to NULL.
> 
> In kvm_vcpu_init_nested() the vcpu->arch.hw_mmu points to &kvm->arch.mmu
> from when it was set in kvm_arch_vcpu_create().
> 
> Normally what happens next is a two step process.  KVM_ARM_VCPU_INIT
> calls kvm_reset_vcpu_core() and that sets the vcpu into hyp context
> (vEL2).  Then KVM_RUN calls kvm_vcpu_load_hw_mmu() which doesn't do
> anything.  But that is fine because we are in hyp context and the
> ->hw_mmu already is pointing to the correct place.
> 
> However if, for example, we are restoring a vcpu that was saved in L2
> context, then the VMM uses KVM_SET_ONE_REG to overwrite the vEL2 state
> that kvm_reset_vcpu_core() set up, and the vCPU is in L2 context when
> KVM_RUN loads it for the first time.  Ideally, kvm_vcpu_load_hw_mmu()
> would set the hw_mm to point to L2's page tables but, since is non-NULL,
> it leaves it as is.  At this point L2 can access L1's memory.

Ah, nice one. You can tell how much testing has gone into
save/restore...

>
> Fix this bug but setting ->hw_mmu to NULL in kvm_vcpu_init_nested() so

nit: s/but/by/

> that kvm_vcpu_load_hw_mmu() always sets it correctly on the first load.
> 
> Fixes: 6ded46b5a4fd ("KVM: arm64: nv: Keep reference on stage-2 MMU when scheduled out")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dan Carpenter <dan@cryspen.com>
> ---
>  arch/arm64/kvm/nested.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 78fa433774c6..60bccb66e52c 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -140,6 +140,8 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
>  		kvm->arch.nested_mmus_size += S2_MMU_PER_VCPU;
>  	}
>  
> +	vcpu->arch.hw_mmu = NULL;
> +

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.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2026-11-11 19:46 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 [this message]
2026-11-12  5:28   ` Dan Carpenter

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=86ld6z1782.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --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=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.