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 B693CC433DB for ; Thu, 18 Mar 2021 09:14:10 +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 2480D64E45 for ; Thu, 18 Mar 2021 09:14:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2480D64E45 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=DR4AOUNCNera2ihGZkEu7Db3uFJVWd2bYoegr26utAI=; b=aJqREhsrGkMVSQ6Qi3Dwu4DZo DWCjKhG2bdCoSVYKGwSe4KiQEkpds3dCEwfAWfeGtbXcNIZqxPA7P1Y+qv/kt196BPuJILoDcAHLW eISihqup8xo+QS70zLi881nrDx+V5ied7AJQLEzKHB0ZlUEQIW05pkERGnGv0KmYTs5kkOtop1x24 XAQ+N2HRQdjPXHJuvucpAFXyfpPV42t18qqcEpzp8YT1GUSVYtglNGVmAZfFD2LcU/fokCDkkP7DV VxhVjNXIM3ugIJduJD2jAnD83WJiASCwafFsMqLkDn9bKDaqjqou4Uqz6uWVotBTFKQu+k9Aj3fLw Injy/1SaQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lMohh-004ro2-5v; Thu, 18 Mar 2021 09:12:29 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMohb-004rni-UX for linux-arm-kernel@lists.infradead.org; Thu, 18 Mar 2021 09:12:26 +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 5AC7D64F2A; Thu, 18 Mar 2021 09:12:22 +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 1lMohY-002MgB-8H; Thu, 18 Mar 2021 09:12:20 +0000 Date: Thu, 18 Mar 2021 09:12:19 +0000 Message-ID: <875z1oj05o.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, dave.martin@arm.com, daniel.kiss@arm.com, Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , broonie@kernel.org, kernel-team@android.com Subject: Re: [PATCH 09/10] KVM: arm64: Save/restore SVE state for nVHE In-Reply-To: <20210317175734.GA5713@willie-the-truck> References: <20210316101312.102925-1-maz@kernel.org> <20210316101312.102925-10-maz@kernel.org> <20210317175734.GA5713@willie-the-truck> 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: will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, dave.martin@arm.com, daniel.kiss@arm.com, catalin.marinas@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, broonie@kernel.org, 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_091224_931853_201FA82C X-CRM114-Status: GOOD ( 31.17 ) 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 Wed, 17 Mar 2021 17:57:35 +0000, Will Deacon wrote: > > On Tue, Mar 16, 2021 at 10:13:11AM +0000, Marc Zyngier wrote: > > Implement the SVE save/restore for nVHE, following a similar > > logic to that of the VHE implementation: > > > > - the SVE state is switched on trap from EL1 to EL2 > > > > - no further changes to ZCR_EL2 occur as long as the guest isn't > > preempted or exit to userspace > > > > - on vcpu_put(), ZCR_EL2 is reset to its default value, and ZCR_EL1 > > restored to the default guest value > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/fpsimd.c | 15 ++++++++-- > > arch/arm64/kvm/hyp/include/hyp/switch.h | 37 +++++++++---------------- > > arch/arm64/kvm/hyp/nvhe/switch.c | 4 +-- > > 3 files changed, 28 insertions(+), 28 deletions(-) > > > > diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c > > index b5f95abd23f5..cc6cdea69596 100644 > > --- a/arch/arm64/kvm/fpsimd.c > > +++ b/arch/arm64/kvm/fpsimd.c > > @@ -121,11 +121,22 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu) > > local_irq_save(flags); > > > > if (vcpu->arch.flags & KVM_ARM64_FP_ENABLED) { > > - if (guest_has_sve) > > + if (guest_has_sve) { > > __vcpu_sys_reg(vcpu, ZCR_EL1) = read_sysreg_el1(SYS_ZCR); > > > > + /* Restore the VL that was saved when bound to the CPU */ > > + if (!has_vhe()) { > > + u64 zcr; > > + > > + kvm_call_hyp(__kvm_reset_sve_vq); > > What would go wrong if we did this unconditionally on return to the host, or > is it just a performance thing to move work off the fast path where we > return back to the same vCPU? Nothing would go wrong, but we'd also need to re-adjust it on entry if the FPSIMD file is dirty, making it doubly painful on the fast path. Doing the reset on vcpu_put() ensures this is only done once, either on preemption or on return to userspace, at the expense of an EL2 round trip. That's consistent with what we do in general for CPU state that doesn't directly affect the execution of the kernel. M. -- 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