All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Mark Brown <broonie@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix confusion in documentation for pKVM SME assert
Date: Tue, 4 Jun 2024 12:17:41 -0700	[thread overview]
Message-ID: <Zl9oVUriFDYbLFW8@linux.dev> (raw)
In-Reply-To: <20240604-kvm-arm64-sme-assert-v1-1-5d98348d00f8@kernel.org>

Hi,

On Tue, Jun 04, 2024 at 07:47:01PM +0100, 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.
> 
> What I believe the check is actually intended to validate is that we do
> not enter the pKVM hypervisor with SME enabled since the pKVM hypervisor
> does not yet understand SME and is therefore unable to save or restore
> host state with SME enabled, indeed attempting to save SVE state would
> fault if streaming mode is enabled on a system without FA64 due to FFR.
> Update the comment to reflect this.

The added context likely isn't necessary in what winds up getting
applied. Can this just directly state the WARN_ON() exists b/c the
protected mode hypervisor doesn't know how to manage SME state?

> Fixes: afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are disabled in protected mode")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/kvm/fpsimd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 521b32868d0d..f720ba47b85c 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -92,8 +92,9 @@ 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.
> +	 * The pKVM hypervisor does not yet understand how to save or
> +	 * restore SME state for the host so double check that if we
> +	 * are running with pKVM we have disabled SME.
>  	 */
>  	WARN_ON(is_protected_kvm_enabled() && system_supports_sme() &&
>  		read_sysreg_s(SYS_SVCR));

While we're here, this should be WARN_ON_ONCE() or WARN_RATELIMIT() if
we _really_ want some spam. But a single WARN ought to be enough.

It'd be a good idea to also document why we're testing for SME state
twice on the KVM_RUN path, as any WARN() in the hyp code is currently
fatal. I'm guessing Fuad meant to have a non-fatal way of getting some
debug information out.

-- 
Thanks,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oliver.upton@linux.dev>
To: Mark Brown <broonie@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Fuad Tabba <tabba@google.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: arm64: Fix confusion in documentation for pKVM SME assert
Date: Tue, 4 Jun 2024 12:17:41 -0700	[thread overview]
Message-ID: <Zl9oVUriFDYbLFW8@linux.dev> (raw)
In-Reply-To: <20240604-kvm-arm64-sme-assert-v1-1-5d98348d00f8@kernel.org>

Hi,

On Tue, Jun 04, 2024 at 07:47:01PM +0100, 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.
> 
> What I believe the check is actually intended to validate is that we do
> not enter the pKVM hypervisor with SME enabled since the pKVM hypervisor
> does not yet understand SME and is therefore unable to save or restore
> host state with SME enabled, indeed attempting to save SVE state would
> fault if streaming mode is enabled on a system without FA64 due to FFR.
> Update the comment to reflect this.

The added context likely isn't necessary in what winds up getting
applied. Can this just directly state the WARN_ON() exists b/c the
protected mode hypervisor doesn't know how to manage SME state?

> Fixes: afb91f5f8ad7 ("KVM: arm64: Ensure that SME controls are disabled in protected mode")
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/kvm/fpsimd.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 521b32868d0d..f720ba47b85c 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -92,8 +92,9 @@ 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.
> +	 * The pKVM hypervisor does not yet understand how to save or
> +	 * restore SME state for the host so double check that if we
> +	 * are running with pKVM we have disabled SME.
>  	 */
>  	WARN_ON(is_protected_kvm_enabled() && system_supports_sme() &&
>  		read_sysreg_s(SYS_SVCR));

While we're here, this should be WARN_ON_ONCE() or WARN_RATELIMIT() if
we _really_ want some spam. But a single WARN ought to be enough.

It'd be a good idea to also document why we're testing for SME state
twice on the KVM_RUN path, as any WARN() in the hyp code is currently
fatal. I'm guessing Fuad meant to have a non-fatal way of getting some
debug information out.

-- 
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-06-04 19:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 18:47 [PATCH] KVM: arm64: Fix confusion in documentation for pKVM SME assert Mark Brown
2024-06-04 18:47 ` Mark Brown
2024-06-04 19:17 ` Oliver Upton [this message]
2024-06-04 19:17   ` Oliver Upton
2024-06-04 20:42   ` Mark Brown
2024-06-04 20:42     ` 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=Zl9oVUriFDYbLFW8@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=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.