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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E66C6C54E67 for ; Sat, 23 Mar 2024 19:06:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=rFoD2S4dmJ6aY4WVCDkkvT0cHDz2siVxtCXNlF7s0kE=; b=bXT2FTJHo0YN1q j85A9ZR/YI52j+5j6YxrIWp3EJg3TDrQODeGpJymPxuja3gu015O+M3wx+MMXcOAKq1ejHyVPUdM2 GfkpjvkOxD4aT3/4nJfVUkV6Z4yKywwOiE8pjuZgkH58RzJcCKs8HSLaAJu3RXAKXI3UNnPPoLpTS kvNTLk3MaqCNB6YJhifRYgTCRAYyk+CThrgd0y+tKLqzktyYYZM9N5z5En/mnAA0dM1CyOaP8rvoG Rw+ivJuNFZo8yWIgf9pPM+yPZl1TyX/0dC9mD+xLb5EFaJASdm2hjms6N68KjYnjFs5BF1dKsXD/X IBRn4cjDqI7Lj040c+Sw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ro6hP-0000000Ay4r-1yUR; Sat, 23 Mar 2024 19:06:35 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ro6hL-0000000Ay49-2y6n for linux-arm-kernel@lists.infradead.org; Sat, 23 Mar 2024 19:06:33 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8292E60B43; Sat, 23 Mar 2024 19:06:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52363C43330; Sat, 23 Mar 2024 19:06:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711220788; bh=WTfe3lrUHJOBTlsrGu5xz4DGupXjIeeLGswZjNtLNKw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ewY/xmNMicY9KBujm8nTwKaPZEkpJUu9YP0YFoPDNyhQKhPG17lNqqkWuQol6f/HK oS1DHZB4d2NZ16svZG0yKOGjy/qhdTVyQPKTiSGZQmreAuDy7S331KvQjYbChPA9qd rT6ErZygXBTjrlnfpMgqWxd3mXxJgwwaJFjbvuWikGmvwlFZFIjtUgDBPrM9BTuRhB v1ZDNt7UvTES0YihzKYAMwqwWevZr/BzR2SBcW8iRBGdvBbif+/16U2wz1XRk9fUOt q0w0eqXDJ5g5HReSoJjctgHw8RCRJmd7YDP6HrYik8MUZ9ehZkLKXM+v6ZdElJ6NeD zf9ppz8Qtbblw== Received: from [193.117.140.69] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ro6hF-00EtFe-Ve; Sat, 23 Mar 2024 19:06:26 +0000 Date: Sat, 23 Mar 2024 19:06:24 +0000 Message-ID: <87edc0sr7z.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , James Clark , Anshuman Khandual , Dongli Zhang Subject: Re: [PATCH v2 5/5] KVM: arm64: Exclude FP ownership from kvm_vcpu_arch In-Reply-To: References: <20240322170945.3292593-1-maz@kernel.org> <20240322170945.3292593-6-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/28.2 (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: 193.117.140.69 X-SA-Exim-Rcpt-To: broonie@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, james.clark@arm.com, anshuman.khandual@arm.com, dongli.zhang@oracle.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-20240323_120631_973478_AAC718AC X-CRM114-Status: GOOD ( 30.76 ) 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 Fri, 22 Mar 2024 17:52:45 +0000, Mark Brown wrote: > > On Fri, Mar 22, 2024 at 05:09:45PM +0000, Marc Zyngier wrote: > > In retrospect, it is fairly obvious that the FP state ownership > > is only meaningful for a given CPU, and that locating this > > information in the vcpu was just a mistake. > > > > Move the ownership tracking into the host data structure, and > > rename it from fp_state to fp_owner, which is a better description > > (name suggested by Mark Brown). > > There's still the thing with the interaction with SME support - to > summarise what I think you're asking for the userspace ABI there: Well, the SME support is still pretty prospective, and this patch has no impact on an existing ABI. > > - Create a requirement for userspace to set SVCR prior to setting any > vector impacted register to ensure the correct format and that data > isn't zeroed when SVCR is set. > - Use the value of SVCR.SM and the guest maximum SVE and SME VLs to > select the currently visible vector length for the Z, P and FFR > registers, and if FFR can be accessed if not available in streaming > mode. > - Changes to SVCR.SM zero register data in the same way writes to the > physical register do. > - This also implies discarding or failing all writes to ZA and ZT0 > unless SVCR.ZA is set for consistency. All of that seems reasonable, as long as it is comes as a consequence of enabling SME. It should be run by the QEMU people though, as they are the ones that will make use of it. Please Cc them when you post the patches or even better, reach out to them beforehand. > - Add support for the V registers in the sysreg interface when SVE is > enabled. We already support the V registers with KVM_REG_ARM_CORE_REG(). Why would you add any new interface for this? The kernel should be perfectly capable of dealing with the placement of the data in the internal structures, and there is no need to tie the userspace ABI to how we deal with that placement (kvm_regs is already purely userspace). > then the implementation can do what it likes to achieve that, the most > obvious thing being to store in native format for the current hardware > mode based on SVCR.{SM,ZA}. Does that sound about right? Apart from the statement about the V registers, this seems OK. But again, I want to see this agreed with the QEMU folks. 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