All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oliver.upton@linux.dev>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes
Date: Thu, 03 Jul 2025 09:52:38 +0100	[thread overview]
Message-ID: <865xg9bqqx.wl-maz@kernel.org> (raw)
In-Reply-To: <aGSbABNGiAaOqSo1@linux.dev>

On Wed, 02 Jul 2025 03:35:44 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Tue, Jul 01, 2025 at 03:22:25PM +0100, Marc Zyngier wrote:
> > Booting an EL2 guest on a system only supporting a subset of the
> > possible page sizes leads to interesting situations.
> > 
> > For example, on a system that only supports 4kB and 64kB, and is
> > booted with a 4kB kernel, we end-up advertising 16kB support at
> > stage-2, which is pretty weird.
> > 
> > That's because we consider that any S2 bigger than our base granule
> > is fair game, irrespective of what the HW actually supports.
> 
> While this is ugly as hell, it is _technically_ OK though right? Since
> we always shadow the stage-2 MMU we can emulate the otherwise
> unsupported page size.
> 
> Now, mismatched granularity at S1 and S2 is a massive can of worms we
> should not entertain :)
> 
> > Add new checks that will verify that this granule size is actually
> > supported before publishing it to the guest.
> > 
> > Fixes: e7ef6ed4583ea ("KVM: arm64: Enforce NV limits on a per-idregs basis")
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> 
> It'd be good to clarify the rationale a bit further in the changelog,
> but full agreement on disallowing this sort of stupidity.

Indeed, I have now added some verbiage to that effect.

> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks!

	M.

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

  reply	other threads:[~2025-07-03  8:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 14:22 [PATCH] KVM: arm64: Fix handling of FEAT_GTG for unimplemented granule sizes Marc Zyngier
2025-07-02  2:35 ` Oliver Upton
2025-07-03  8:52   ` Marc Zyngier [this message]
2025-07-03  9:41 ` Marc Zyngier

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=865xg9bqqx.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=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --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.