Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
Date: Tue, 26 May 2026 11:19:38 +0100	[thread overview]
Message-ID: <b4fdceb6-5fa7-4829-a60e-6f80f47f032a@sirena.org.uk> (raw)
In-Reply-To: <ahSWwl-uCv4ZW-nE@J2N7QTR9R3>

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Mon, May 25, 2026 at 07:36:50PM +0100, Mark Rutland wrote:
> On Fri, May 22, 2026 at 07:00:04PM +0100, Mark Brown wrote:

> > Since b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") when guests
> > write to ZCR_EL2 we have clamped the value of ZCR_EL2.LEN to be at most
> > that configuring the maximum guest VL. This is not the behaviour the

...

> Have we sought feedback from architects? While I said "*or* the
> architcture requires a clarification", I think it should be clarified
> more explicitly either way given that the pattern is unusual.

> Given this is particularly subtle, please keep me in the loop when
> speaking with architects about this.

TBH it didn't strike me as subtle, I don't see anything in the
architecture which would lead me to expect the current behaviour.  The
psudocode all just has direct assignments for the write and there's
language in the ARM (eg, in the ZCR_EL2 description) saying "for all
purposes other than returning the result of a direct read of ZCR_EL2"
which seems specifically intended to cover there being a divergence
between the written and effective values, though I guess it doesn't
explicitly mention writes in the text.  

When I saw the code it looked like something KVM was doing for some
KVM reason that was obscure to me, the lack of clarity seemed like it
was on the KVM side.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2026-05-26 10:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-22 18:00 [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values Mark Brown
2026-05-23  8:47 ` Marc Zyngier
2026-05-23 14:38   ` Mark Brown
2026-05-23 15:24     ` Marc Zyngier
2026-05-25 18:36 ` Mark Rutland
2026-05-26 10:19   ` Mark Brown [this message]
2026-05-26 12:03     ` Mark Rutland
2026-05-26 13:03       ` Mark Brown

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=b4fdceb6-5fa7-4829-a60e-6f80f47f032a@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox