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 890E0C43334 for ; Sat, 4 Jun 2022 08:10:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 11F3B4B2CC; Sat, 4 Jun 2022 04:10:08 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org 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 XLCtcCIeYOqj; Sat, 4 Jun 2022 04:10:06 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EE3344B2D9; Sat, 4 Jun 2022 04:10:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9BDBE49F35 for ; Sat, 4 Jun 2022 04:10:06 -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 elxWIL-EX6b5 for ; Sat, 4 Jun 2022 04:10:05 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 6B51D4B1E7 for ; Sat, 4 Jun 2022 04:10:05 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 46A8360AD9; Sat, 4 Jun 2022 08:10:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E542C385B8; Sat, 4 Jun 2022 08:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654330203; bh=m8atLHg10uMBvCwOiHa5NmvHe5U3T9fGavEysDs06ig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Q9nlSQlgUQgHhKqQFNcJP6QyRIINosbrtee16VhRS28GulZOE6Zr5VX3bgY/2WlQX qDnxxS5a8pNadnxIjsd5djKy4ZgLqFEF2Q8ZelmcbXCQoiVsLvWjXqx7mnBvnv/1LP 4hcgzJz6J4Jltq2l84AQXdHTn3Hni3LDvjkDN4PKdgSl5uSdM2ctNE9dHvUzABidzc sRDIBLH6I4QiKl0T3Ji1VGVhrXnwVRDxrspVTV8n9rR6/DwzEYLShSpCRF1tE/iSfg 66YtvfdUsPY5spZnoHFo63QS4ZQoOHFr0+i++7aFpMY+0BviulRytghzdLSLJfWQiv gWLTakk/pwEtQ== Received: from host217-45-173-31.in-addr.btopenworld.com ([217.45.173.31] 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.94.2) (envelope-from ) id 1nxOrB-00FaF6-44; Sat, 04 Jun 2022 09:10:01 +0100 Date: Sat, 04 Jun 2022 09:10:01 +0100 Message-ID: <87wndwluhy.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Subject: Re: [PATCH 03/18] KVM: arm64: Drop FP_FOREIGN_STATE from the hypervisor code In-Reply-To: References: <20220528113829.1043361-1-maz@kernel.org> <20220528113829.1043361-4-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: 217.45.173.31 X-SA-Exim-Rcpt-To: reijiw@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, will@kernel.org, broonie@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: kvm@vger.kernel.org, kernel-team@android.com, Mark Brown , Will Deacon , kvmarm@lists.cs.columbia.edu, Linux ARM 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 Fri, 03 Jun 2022 06:23:25 +0100, Reiji Watanabe wrote: > > Hi Marc, > > On Sat, May 28, 2022 at 4:38 AM Marc Zyngier wrote: > > > > The vcpu KVM_ARM64_FP_FOREIGN_FPSTATE flag tracks the thread's own > > TIF_FOREIGN_FPSTATE so that we can evaluate just before running > > the vcpu whether it the FP regs contain something that is owned > > by the vcpu or not by updating the rest of the FP flags. > > > > We do this in the hypervisor code in order to make sure we're > > in a context where we are not interruptible. But we already > > have a hook in the run loop to generate this flag. We may as > > well update the FP flags directly and save the pointless flag > > tracking. > > > > Whilst we're at it, rename update_fp_enabled() to guest_owns_fp_regs() > > to indicate what the leftover of this helper actually do. > > > > Signed-off-by: Marc Zyngier > > Reviewed-by: Reiji Watanabe > > > > --- a/arch/arm64/kvm/fpsimd.c > > +++ b/arch/arm64/kvm/fpsimd.c > > @@ -107,16 +107,19 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) > > } > > > > /* > > - * Called just before entering the guest once we are no longer > > - * preemptable. Syncs the host's TIF_FOREIGN_FPSTATE with the KVM > > - * mirror of the flag used by the hypervisor. > > + * Called just before entering the guest once we are no longer preemptable > > + * and interrupts are disabled. If we have managed to run anything using > > + * FP while we were preemptible (such as off the back of an interrupt), > > + * then neither the host nor the guest own the FP hardware (and it was the > > + * responsibility of the code that used FP to save the existing state). > > + * > > + * Note that not supporting FP is basically the same thing as far as the > > + * hypervisor is concerned (nothing to save). > > */ > > void kvm_arch_vcpu_ctxflush_fp(struct kvm_vcpu *vcpu) > > { > > - if (test_thread_flag(TIF_FOREIGN_FPSTATE)) > > - vcpu->arch.flags |= KVM_ARM64_FP_FOREIGN_FPSTATE; > > - else > > - vcpu->arch.flags &= ~KVM_ARM64_FP_FOREIGN_FPSTATE; > > + if (!system_supports_fpsimd() || test_thread_flag(TIF_FOREIGN_FPSTATE)) > > + vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_FP_HOST); > > } > > Although kvm_arch_vcpu_load_fp() unconditionally sets KVM_ARM64_FP_HOST, > perhaps having kvm_arch_vcpu_load_fp() set KVM_ARM64_FP_HOST only when > FP is supported might be more consistent? > Then, checking system_supports_fpsimd() is unnecessary here. > (KVM_ARM64_FP_ENABLED is not set when FP is not supported) That's indeed a possibility. But I'm trying not to change the logic here, only to move it to a place that provides the same semantic without the need for an extra flag. I'm happy to stack an extra patch on top of this series though. Thanks, 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 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 E25A2C43334 for ; Sat, 4 Jun 2022 08:11:56 +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=DiKEhAacIJK4flqrxWuJJ0NTYIgGOXxSQyNRW/3Tz4g=; b=JCr6wZwAq9Y8px RZhKgHvlSmL4/94VR8XFtxp0bB1RGSMq9BB7o7AWgX8qf3v3+mrCYfZ3VYurc2aSH+hdc/Us8W1+a hVnPX48IUbAKRCz6cs4aZ2UaAUKpLBTtN/DONoO6ANyEyaUk24GCsQXuxsWYnZO/xWc+D0CRzPSUZ P7qmLVRCQweh76FlGYdPpwx7k+wb0taSqJSAfVt4t6JuPG4SnY1WCzXzphxjA0oA5iU9tqzf3Dg7X fDopHf/zj3rOZVIEsu8IiaP20gXV13vZQIOBV92XKU2leWa1k1gY+9QL3TctwYNMBFD9T5WjEFygs juZVz7QYJXEF9EhTb4cA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nxOrS-00AmGd-Gx; Sat, 04 Jun 2022 08:10:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nxOrN-00AmE9-F7 for linux-arm-kernel@lists.infradead.org; Sat, 04 Jun 2022 08:10:16 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 46A8360AD9; Sat, 4 Jun 2022 08:10:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E542C385B8; Sat, 4 Jun 2022 08:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654330203; bh=m8atLHg10uMBvCwOiHa5NmvHe5U3T9fGavEysDs06ig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Q9nlSQlgUQgHhKqQFNcJP6QyRIINosbrtee16VhRS28GulZOE6Zr5VX3bgY/2WlQX qDnxxS5a8pNadnxIjsd5djKy4ZgLqFEF2Q8ZelmcbXCQoiVsLvWjXqx7mnBvnv/1LP 4hcgzJz6J4Jltq2l84AQXdHTn3Hni3LDvjkDN4PKdgSl5uSdM2ctNE9dHvUzABidzc sRDIBLH6I4QiKl0T3Ji1VGVhrXnwVRDxrspVTV8n9rR6/DwzEYLShSpCRF1tE/iSfg 66YtvfdUsPY5spZnoHFo63QS4ZQoOHFr0+i++7aFpMY+0BviulRytghzdLSLJfWQiv gWLTakk/pwEtQ== Received: from host217-45-173-31.in-addr.btopenworld.com ([217.45.173.31] 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.94.2) (envelope-from ) id 1nxOrB-00FaF6-44; Sat, 04 Jun 2022 09:10:01 +0100 Date: Sat, 04 Jun 2022 09:10:01 +0100 Message-ID: <87wndwluhy.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , kernel-team@android.com, Will Deacon , Mark Brown Subject: Re: [PATCH 03/18] KVM: arm64: Drop FP_FOREIGN_STATE from the hypervisor code In-Reply-To: References: <20220528113829.1043361-1-maz@kernel.org> <20220528113829.1043361-4-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: 217.45.173.31 X-SA-Exim-Rcpt-To: reijiw@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, will@kernel.org, broonie@kernel.org 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-20220604_011013_626368_1B4B7FDA X-CRM114-Status: GOOD ( 36.19 ) 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, 03 Jun 2022 06:23:25 +0100, Reiji Watanabe wrote: > > Hi Marc, > > On Sat, May 28, 2022 at 4:38 AM Marc Zyngier wrote: > > > > The vcpu KVM_ARM64_FP_FOREIGN_FPSTATE flag tracks the thread's own > > TIF_FOREIGN_FPSTATE so that we can evaluate just before running > > the vcpu whether it the FP regs contain something that is owned > > by the vcpu or not by updating the rest of the FP flags. > > > > We do this in the hypervisor code in order to make sure we're > > in a context where we are not interruptible. But we already > > have a hook in the run loop to generate this flag. We may as > > well update the FP flags directly and save the pointless flag > > tracking. > > > > Whilst we're at it, rename update_fp_enabled() to guest_owns_fp_regs() > > to indicate what the leftover of this helper actually do. > > > > Signed-off-by: Marc Zyngier > > Reviewed-by: Reiji Watanabe > > > > --- a/arch/arm64/kvm/fpsimd.c > > +++ b/arch/arm64/kvm/fpsimd.c > > @@ -107,16 +107,19 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) > > } > > > > /* > > - * Called just before entering the guest once we are no longer > > - * preemptable. Syncs the host's TIF_FOREIGN_FPSTATE with the KVM > > - * mirror of the flag used by the hypervisor. > > + * Called just before entering the guest once we are no longer preemptable > > + * and interrupts are disabled. If we have managed to run anything using > > + * FP while we were preemptible (such as off the back of an interrupt), > > + * then neither the host nor the guest own the FP hardware (and it was the > > + * responsibility of the code that used FP to save the existing state). > > + * > > + * Note that not supporting FP is basically the same thing as far as the > > + * hypervisor is concerned (nothing to save). > > */ > > void kvm_arch_vcpu_ctxflush_fp(struct kvm_vcpu *vcpu) > > { > > - if (test_thread_flag(TIF_FOREIGN_FPSTATE)) > > - vcpu->arch.flags |= KVM_ARM64_FP_FOREIGN_FPSTATE; > > - else > > - vcpu->arch.flags &= ~KVM_ARM64_FP_FOREIGN_FPSTATE; > > + if (!system_supports_fpsimd() || test_thread_flag(TIF_FOREIGN_FPSTATE)) > > + vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_FP_HOST); > > } > > Although kvm_arch_vcpu_load_fp() unconditionally sets KVM_ARM64_FP_HOST, > perhaps having kvm_arch_vcpu_load_fp() set KVM_ARM64_FP_HOST only when > FP is supported might be more consistent? > Then, checking system_supports_fpsimd() is unnecessary here. > (KVM_ARM64_FP_ENABLED is not set when FP is not supported) That's indeed a possibility. But I'm trying not to change the logic here, only to move it to a place that provides the same semantic without the need for an extra flag. I'm happy to stack an extra patch on top of this series though. Thanks, 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 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3142C433EF for ; Sat, 4 Jun 2022 08:10:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233427AbiFDIKH (ORCPT ); Sat, 4 Jun 2022 04:10:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232057AbiFDIKF (ORCPT ); Sat, 4 Jun 2022 04:10:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B204F38BC7 for ; Sat, 4 Jun 2022 01:10:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4896D60EFE for ; Sat, 4 Jun 2022 08:10:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E542C385B8; Sat, 4 Jun 2022 08:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654330203; bh=m8atLHg10uMBvCwOiHa5NmvHe5U3T9fGavEysDs06ig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Q9nlSQlgUQgHhKqQFNcJP6QyRIINosbrtee16VhRS28GulZOE6Zr5VX3bgY/2WlQX qDnxxS5a8pNadnxIjsd5djKy4ZgLqFEF2Q8ZelmcbXCQoiVsLvWjXqx7mnBvnv/1LP 4hcgzJz6J4Jltq2l84AQXdHTn3Hni3LDvjkDN4PKdgSl5uSdM2ctNE9dHvUzABidzc sRDIBLH6I4QiKl0T3Ji1VGVhrXnwVRDxrspVTV8n9rR6/DwzEYLShSpCRF1tE/iSfg 66YtvfdUsPY5spZnoHFo63QS4ZQoOHFr0+i++7aFpMY+0BviulRytghzdLSLJfWQiv gWLTakk/pwEtQ== Received: from host217-45-173-31.in-addr.btopenworld.com ([217.45.173.31] 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.94.2) (envelope-from ) id 1nxOrB-00FaF6-44; Sat, 04 Jun 2022 09:10:01 +0100 Date: Sat, 04 Jun 2022 09:10:01 +0100 Message-ID: <87wndwluhy.wl-maz@kernel.org> From: Marc Zyngier To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , kernel-team@android.com, Will Deacon , Mark Brown Subject: Re: [PATCH 03/18] KVM: arm64: Drop FP_FOREIGN_STATE from the hypervisor code In-Reply-To: References: <20220528113829.1043361-1-maz@kernel.org> <20220528113829.1043361-4-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 X-SA-Exim-Connect-IP: 217.45.173.31 X-SA-Exim-Rcpt-To: reijiw@google.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, will@kernel.org, broonie@kernel.org 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 Fri, 03 Jun 2022 06:23:25 +0100, Reiji Watanabe wrote: > > Hi Marc, > > On Sat, May 28, 2022 at 4:38 AM Marc Zyngier wrote: > > > > The vcpu KVM_ARM64_FP_FOREIGN_FPSTATE flag tracks the thread's own > > TIF_FOREIGN_FPSTATE so that we can evaluate just before running > > the vcpu whether it the FP regs contain something that is owned > > by the vcpu or not by updating the rest of the FP flags. > > > > We do this in the hypervisor code in order to make sure we're > > in a context where we are not interruptible. But we already > > have a hook in the run loop to generate this flag. We may as > > well update the FP flags directly and save the pointless flag > > tracking. > > > > Whilst we're at it, rename update_fp_enabled() to guest_owns_fp_regs() > > to indicate what the leftover of this helper actually do. > > > > Signed-off-by: Marc Zyngier > > Reviewed-by: Reiji Watanabe > > > > --- a/arch/arm64/kvm/fpsimd.c > > +++ b/arch/arm64/kvm/fpsimd.c > > @@ -107,16 +107,19 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu) > > } > > > > /* > > - * Called just before entering the guest once we are no longer > > - * preemptable. Syncs the host's TIF_FOREIGN_FPSTATE with the KVM > > - * mirror of the flag used by the hypervisor. > > + * Called just before entering the guest once we are no longer preemptable > > + * and interrupts are disabled. If we have managed to run anything using > > + * FP while we were preemptible (such as off the back of an interrupt), > > + * then neither the host nor the guest own the FP hardware (and it was the > > + * responsibility of the code that used FP to save the existing state). > > + * > > + * Note that not supporting FP is basically the same thing as far as the > > + * hypervisor is concerned (nothing to save). > > */ > > void kvm_arch_vcpu_ctxflush_fp(struct kvm_vcpu *vcpu) > > { > > - if (test_thread_flag(TIF_FOREIGN_FPSTATE)) > > - vcpu->arch.flags |= KVM_ARM64_FP_FOREIGN_FPSTATE; > > - else > > - vcpu->arch.flags &= ~KVM_ARM64_FP_FOREIGN_FPSTATE; > > + if (!system_supports_fpsimd() || test_thread_flag(TIF_FOREIGN_FPSTATE)) > > + vcpu->arch.flags &= ~(KVM_ARM64_FP_ENABLED | KVM_ARM64_FP_HOST); > > } > > Although kvm_arch_vcpu_load_fp() unconditionally sets KVM_ARM64_FP_HOST, > perhaps having kvm_arch_vcpu_load_fp() set KVM_ARM64_FP_HOST only when > FP is supported might be more consistent? > Then, checking system_supports_fpsimd() is unnecessary here. > (KVM_ARM64_FP_ENABLED is not set when FP is not supported) That's indeed a possibility. But I'm trying not to change the logic here, only to move it to a place that provides the same semantic without the need for an extra flag. I'm happy to stack an extra patch on top of this series though. Thanks, M. -- Without deviation from the norm, progress is not possible.