All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>, Marc Zyngier <maz@kernel.org>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org, Fuad Tabba <tabba@google.com>,
	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: Wed, 12 Feb 2025 22:14:29 -0800	[thread overview]
Message-ID: <Z62NxRzbOyt-nBmK@linux.dev> (raw)
In-Reply-To: <Z6yByMUBPDUyEWOr@J2N7QTR9R3>

On Wed, Feb 12, 2025 at 11:11:04AM +0000, Mark Rutland 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>

I don't think a Fixes tag is warranted here, this doesn't fix any
functional issue.

> > 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.

I'll pick it up for 6.15 if Marc doesn't grab it as a fix.

-- 
Thanks,
Oliver

  reply	other threads:[~2025-02-13  6:14 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 [this message]
2025-02-13  8:55   ` Marc Zyngier
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=Z62NxRzbOyt-nBmK@linux.dev \
    --to=oliver.upton@linux.dev \
    --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=maz@kernel.org \
    --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.