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.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 72CC2C433E6 for ; Thu, 18 Mar 2021 18:40:22 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id E38BC64F38 for ; Thu, 18 Mar 2021 18:40:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E38BC64F38 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 784854B75E; Thu, 18 Mar 2021 14:40:21 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNbs6168jfcj; Thu, 18 Mar 2021 14:40:20 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 572974B760; Thu, 18 Mar 2021 14:40:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id CB0EA4B756 for ; Thu, 18 Mar 2021 14:40:19 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDXJDxiiEC04 for ; Thu, 18 Mar 2021 14:40:18 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9CAAE4B379 for ; Thu, 18 Mar 2021 14:40:18 -0400 (EDT) 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 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 Cc: kernel-team@android.com, Catalin Marinas , broonie@kernel.org, Will Deacon , dave.martin@arm.com, daniel.kiss@arm.com X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 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.0 required=3.0 tests=BAYES_00,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 34528C43381 for ; Thu, 18 Mar 2021 18:41:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0215064F1B for ; Thu, 18 Mar 2021 18:41:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232667AbhCRSkc convert rfc822-to-8bit (ORCPT ); Thu, 18 Mar 2021 14:40:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:44454 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232653AbhCRSkR (ORCPT ); Thu, 18 Mar 2021 14:40:17 -0400 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") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT 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 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.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.