linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org
Cc: dave.martin@arm.com, daniel.kiss@arm.com,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	broonie@kernel.org, ascull@google.com, qperret@google.com,
	kernel-team@android.com
Subject: Re: [PATCH v2 09/11] KVM: arm64: Trap host SVE accesses when the FPSIMD state is dirty
Date: Thu, 18 Mar 2021 18:40:13 +0000	[thread overview]
Message-ID: <87y2ekgvaq.wl-maz@kernel.org> (raw)
In-Reply-To: <20210318122532.505263-10-maz@kernel.org>

On Thu, 18 Mar 2021 12:25:30 +0000,
Marc Zyngier <maz@kernel.org> wrote:
> 
> ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to
> a potentially lower limit when the guest uses SVE. In order
> to restore the SVE state on the EL1 host, we must first
> reset ZCR_EL2 to its original value.
> 
> To make it as lazy as possible on the EL1 host side, set
> the SVE trapping in place when returning exiting from
> the guest. On the first EL1 access to SVE, ZCR_EL2 will
> be restored to its full glory.
> 
> Suggested-by: Andrew Scull <ascull@google.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  arch/arm64/kvm/hyp/nvhe/hyp-main.c | 4 ++++
>  arch/arm64/kvm/hyp/nvhe/switch.c   | 9 +++++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index f012f8665ecc..8d04d69edd15 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -177,6 +177,10 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
>  	case ESR_ELx_EC_SMC64:
>  		handle_host_smc(host_ctxt);
>  		break;
> +	case ESR_ELx_EC_SVE:
> +		sve_cond_update_zcr_vq(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
> +		sysreg_clear_set(cptr_el2, CPTR_EL2_TZ, 0);
> +		break;

It turns out that my last test-run was flawed, as my model was stuck
with VHE, meaning this snippet was never run. If it ran, I would have
noticed that CPTR_EL2.TZ being set results in the ZCR_EL2 access to
trap at EL2, meaning the above explodes very quickly.

I've queued the below patch on top of the existing series, which cures
the issue and let the tests run for real this time.

Thanks to Will for the timely report, and apologies for the lousy
testing...

	M.

From 5b08709313718e95ba06ef49aa82f964a605bd9c Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz@kernel.org>
Date: Thu, 18 Mar 2021 18:30:26 +0000
Subject: [PATCH] KVM: arm64: Fix host's ZCR_EL2 restore on nVHE

We re-enter the EL1 host with CPTR_EL2.TZ set in order to
be able to lazily restore ZCR_EL2 when required.

However, the same CPTR_EL2 configuration also leads to trapping
when ZCR_EL2 is accessed from EL2. Duh!

Clear CPTR_EL2.TZ *before* writing to ZCR_EL2.

Fixes: beed09067b42 ("KVM: arm64: Trap host SVE accesses when the FPSIMD state is dirty")
Reported-by: Will Deacon <will@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kvm/hyp/nvhe/hyp-main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 8d04d69edd15..84a702dc4a92 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -178,8 +178,9 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
 		handle_host_smc(host_ctxt);
 		break;
 	case ESR_ELx_EC_SVE:
-		sve_cond_update_zcr_vq(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
 		sysreg_clear_set(cptr_el2, CPTR_EL2_TZ, 0);
+		isb();
+		sve_cond_update_zcr_vq(ZCR_ELx_LEN_MASK, SYS_ZCR_EL2);
 		break;
 	default:
 		hyp_panic();
-- 
2.29.2


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

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

  parent reply	other threads:[~2021-03-18 18:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 12:25 [PATCH v2 00/11] KVM: arm64: Enable SVE support on nVHE systems Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 01/11] KVM: arm64: Provide KVM's own save/restore SVE primitives Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 02/11] KVM: arm64: Use {read, write}_sysreg_el1 to access ZCR_EL1 Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 03/11] KVM: arm64: Let vcpu_sve_pffr() handle HYP VAs Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 04/11] KVM: arm64: Introduce vcpu_sve_vq() helper Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 05/11] arm64: sve: Provide a conditional update accessor for ZCR_ELx Marc Zyngier
2021-03-18 13:32   ` Will Deacon
2021-03-19 16:42   ` Mark Brown
2021-03-19 16:51     ` Marc Zyngier
2021-03-19 16:58       ` Mark Brown
2021-03-18 12:25 ` [PATCH v2 06/11] KVM: arm64: Rework SVE host-save/guest-restore Marc Zyngier
2021-03-18 13:34   ` Will Deacon
2021-03-18 12:25 ` [PATCH v2 07/11] KVM: arm64: Map SVE context at EL2 when available Marc Zyngier
2021-03-18 13:35   ` Will Deacon
2021-03-18 12:25 ` [PATCH v2 08/11] KVM: arm64: Save guest's ZCR_EL1 before saving the FPSIMD state Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 09/11] KVM: arm64: Trap host SVE accesses when the FPSIMD state is dirty Marc Zyngier
2021-03-18 14:11   ` Will Deacon
2021-03-18 14:29     ` Marc Zyngier
2021-03-18 18:40   ` Marc Zyngier [this message]
2021-03-18 12:25 ` [PATCH v2 10/11] KVM: arm64: Save/restore SVE state for nVHE Marc Zyngier
2021-03-18 14:13   ` Will Deacon
2021-03-18 14:32     ` Marc Zyngier
2021-03-18 12:25 ` [PATCH v2 11/11] KVM: arm64: Enable SVE support " Marc Zyngier
2021-03-19 17:53 ` [PATCH v2 00/11] KVM: arm64: Enable SVE support on nVHE systems 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=87y2ekgvaq.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=ascull@google.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.kiss@arm.com \
    --cc=dave.martin@arm.com \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=qperret@google.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;
as well as URLs for NNTP newsgroup(s).