From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org, Fuad Tabba <tabba@google.com>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v7] KVM: arm64: Fix confusion in documentation for pKVM SME assert
Date: Thu, 13 Feb 2025 08:55:52 +0000 [thread overview]
Message-ID: <86tt8yrzon.wl-maz@kernel.org> (raw)
In-Reply-To: <Z6yByMUBPDUyEWOr@J2N7QTR9R3>
On Wed, 12 Feb 2025 11:11:04 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Wed, Feb 12, 2025 at 12:44:57AM +0000, Mark Brown wrote:
> > As raised in the review comments for the original patch the assert and
> > comment added in afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are
> > disabled in protected mode") are bogus. The comments says that we check
> > that we do not have SME enabled for a pKVM guest but the assert actually
> > checks to see if the host has anything set in SVCR which is unrelated to
> > the guest features or state, regardless of if those guests are protected
> > or not. This check is also made in the hypervisor, it will refuse to run
> > a guest if the check fails, so it appears that the assert here is
> > intended to improve diagnostics.
> >
> > Update the comment to reflect the check in the code, and to clarify that
> > we do actually enforce this in the hypervisor. While we're here also
> > update to use a WARN_ON_ONCE() to avoid log spam if this triggers.
> >
> > Fixes: afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are disabled in protected mode")
> > Reviewed-by: Fuad Tabba <tabba@google.com>
> > Signed-off-by: Mark Brown <broonie@kernel.org>
> > ---
> > This has been sent with v6.10 with only positive review comments after
> > the first revision, if there is some issue with the change please share
> > it.
> >
> > To: Marc Zyngier <maz@kernel.org>
> > To: Oliver Upton <oliver.upton@linux.dev>
> > To: James Morse <james.morse@arm.com>
> > To: Suzuki K Poulose <suzuki.poulose@arm.com>
> > To: Catalin Marinas <catalin.marinas@arm.com>
> > To: Will Deacon <will@kernel.org>
> > To: Fuad Tabba <tabba@google.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > ---
> > Changes in v7:
> > - Reword the comment.
> > - Link to v6: https://lore.kernel.org/r/20250210-kvm-arm64-sme-assert-v6-1-cc26c46d1b43@kernel.org
> >
> > Changes in v6:
> > - Rebase onto v6.14-rc1.
> > - Link to v5: https://lore.kernel.org/r/20241210-kvm-arm64-sme-assert-v5-1-995c8dd1025b@kernel.org
> >
> > Changes in v5:
> > - Rebase onto v6.13-rc1.
> > - Link to v4: https://lore.kernel.org/r/20240930-kvm-arm64-sme-assert-v4-1-3c9df71db688@kernel.org
> >
> > Changes in v4:
> > - Rebase onto v6.12-rc1
> > - Link to v3: https://lore.kernel.org/r/20240730-kvm-arm64-sme-assert-v3-1-8699454e5cb8@kernel.org
> >
> > Changes in v3:
> > - Rebase onto v6.11-rc1.
> > - Link to v2: https://lore.kernel.org/r/20240605-kvm-arm64-sme-assert-v2-1-54391b0032f4@kernel.org
> >
> > Changes in v2:
> > - Commit message tweaks.
> > - Change the assert to WARN_ON_ONCE().
> > - Link to v1: https://lore.kernel.org/r/20240604-kvm-arm64-sme-assert-v1-1-5d98348d00f8@kernel.org
> > ---
> > arch/arm64/kvm/fpsimd.c | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> > index 4d3d1a2eb157047b4b2488e9c4ffaabc6f5a0818..e37e53883c357093ff4455f5afdaec90e662d744 100644
> > --- a/arch/arm64/kvm/fpsimd.c
> > +++ b/arch/arm64/kvm/fpsimd.c
> > @@ -93,11 +93,14 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> > }
> >
> > /*
> > - * If normal guests gain SME support, maintain this behavior for pKVM
> > - * guests, which don't support SME.
> > + * Protected and non-protected KVM modes require that
> > + * SVCR.{SM,ZA} == {0,0} when entering a guest so that no
> > + * host/guest SME state needs to be saved/restored by hyp code.
> > + *
> > + * In protected mode, hyp code will verify this later.
> > */
> > - WARN_ON(is_protected_kvm_enabled() && system_supports_sme() &&
> > - read_sysreg_s(SYS_SVCR));
> > + WARN_ON_ONCE(is_protected_kvm_enabled() && system_supports_sme() &&
> > + read_sysreg_s(SYS_SVCR));
>
> As I mentioned on the last round, we can drop the is_protected_kvm_enabled()
> check, i.e. have:
>
> /*
> * Protected and non-protected KVM modes require that
> * SVCR.{SM,ZA} == {0,0} when entering a guest so that no
> * host/guest SME state needs to be saved/restored by hyp code.
> *
> * In protected mode, hyp code will verify this later.
> */
> WARN_ON_ONCE(system_supports_sme() && read_sysreg_s(SYS_SVCR));
>
> Either way:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Marc, are you happy to queue this atop the recent fixes from me? Those
> try to ensure SVCR.{SM,ZA} == {0,0} regardless of whether KVM is in
> protected mode.
In all honesty, I find that at this stage, the comment just gets in
the way and is over-describing what is at stake here.
The
WARN_ON_ONCE(system_supports_sme() && read_sysreg_s(SYS_SVCR));
is really the only thing that matters. It perfectly shows what we are
checking for, and doesn't need an exegesis.
As for the Fixes: tag, and given the magnitude of the actual fixes
that are already queued, I don't think we need it.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-02-13 8:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 0:44 [PATCH v7] KVM: arm64: Fix confusion in documentation for pKVM SME assert Mark Brown
2025-02-12 11:11 ` Mark Rutland
2025-02-13 6:14 ` Oliver Upton
2025-02-13 8:55 ` Marc Zyngier [this message]
2025-02-13 9:24 ` Mark Rutland
2025-02-13 10:56 ` 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=86tt8yrzon.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@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=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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 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.