From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 036AAC433E6 for ; Thu, 18 Mar 2021 18:42:08 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7A2C864F01 for ; Thu, 18 Mar 2021 18:42:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A2C864F01 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GgENQHfkfksxhCcO4xDphOm0RKBkH+D4znbJ2PFwduo=; b=HxIjNrelj3QonHNBvCKidqOiu MVNldZJombicrVeQZcj/JQNow8h2B0dQvaZvhXibU5g8jKPU3kGNsI9O6huhSv3jjr+4mOUYAPhSp enDyJ6RGCvCVkWHNYfk5AUbP9DZpO5YM0Rsht17nA02VL4xc11YETJo3M/JSlGvKHDc9/xHD9v1C8 zOMZ8p5MyOJGD2A+pZuiT529xszbQh5OJQCfCcqSEYBv5xvRAot24mA/LomgZrsjZqs5oPkhHi4Jv KIPki0kDzhmx2xq29rJQTluTOBk06ZL68/SsUcPH3hGZ5B6etSp4hYjJlHvS9qZKxkgYsqM1srur8 szw9hYZSQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lMxZH-005rWJ-6h; Thu, 18 Mar 2021 18:40:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMxZD-005rVQ-1Z for linux-arm-kernel@lists.infradead.org; Thu, 18 Mar 2021 18:40:21 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4421D64F30; Thu, 18 Mar 2021 18:40:17 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lMxZ9-002St3-20; Thu, 18 Mar 2021 18:40:15 +0000 Date: Thu, 18 Mar 2021 18:40:13 +0000 Message-ID: <87y2ekgvaq.wl-maz@kernel.org> From: Marc Zyngier 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 , Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , 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 In-Reply-To: <20210318122532.505263-10-maz@kernel.org> References: <20210318122532.505263-1-maz@kernel.org> <20210318122532.505263-10-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, dave.martin@arm.com, daniel.kiss@arm.com, will@kernel.org, catalin.marinas@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, broonie@kernel.org, ascull@google.com, qperret@google.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210318_184019_485458_8BB7DD9F X-CRM114-Status: GOOD ( 29.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 18 Mar 2021 12:25:30 +0000, Marc Zyngier 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 > Signed-off-by: Marc Zyngier > --- > 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 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 Signed-off-by: Marc Zyngier --- 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