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 Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83068C433EF for ; Mon, 22 Nov 2021 18:10:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0BB6A4B0E1; Mon, 22 Nov 2021 13:10:33 -0500 (EST) 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 bUxAfQBe1oxC; Mon, 22 Nov 2021 13:10:31 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B9C044B0E6; Mon, 22 Nov 2021 13:10:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6A8BA4B0E1 for ; Mon, 22 Nov 2021 13:10:31 -0500 (EST) 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 JLDDS7dcR8kY for ; Mon, 22 Nov 2021 13:10:30 -0500 (EST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E0AFE4B0C5 for ; Mon, 22 Nov 2021 13:10:29 -0500 (EST) 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 9DAD360C4A; Mon, 22 Nov 2021 18:10:28 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] 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.2) (envelope-from ) id 1mpDlq-0076tI-GG; Mon, 22 Nov 2021 18:10:26 +0000 Date: Mon, 22 Nov 2021 18:10:25 +0000 Message-ID: <87v90kcb8u.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Subject: Re: [PATCH v2 2/5] KVM: arm64: Get rid of host SVE tracking/saving In-Reply-To: References: <20211028111640.3663631-1-maz@kernel.org> <20211028111640.3663631-3-maz@kernel.org> <5ab3836f-2b39-2ff5-3286-8258addd01e4@huawei.com> <871r38dvyr.wl-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: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, yuzenghui@huawei.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, qperret@google.com, will@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 Cc: kernel-team@android.com, kvm@vger.kernel.org, Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org 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 Mon, 22 Nov 2021 17:58:00 +0000, Mark Brown wrote: > > On Mon, Nov 22, 2021 at 03:57:32PM +0000, Marc Zyngier wrote: > > Zenghui Yu wrote: > > > > Nit: This removes the only user of __sve_save_state() helper. Should we > > > still keep it in fpsimd.S? > > > I was in two minds about that, as I'd like to eventually be able to > > use SVE for protected guests, where the hypervisor itself has to be in > > charge of the FP/SVE save-restore. > > > But that's probably several months away, and I can always revert a > > deletion patch if I need to, so let's get rid of it now. > > While we're on the subject of potential future work we might in future > want to not disable SVE on every syscall if (as seems likely) it turns > out that that's more performant for small vector lengths [...] How are you going to retrofit that into userspace? This would be an ABI change, and I'm not sure how you'd want to deal with that transition... M. -- 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