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 A940BC433EF for ; Fri, 3 Jun 2022 05:24:53 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UWtIf//z1mIpIxHuAUPOsv+xZEeGrNNQ5PIulxXUAn4=; b=zF59I5a3mqGwGW IyMb3NdrZecn19I2D0R1ZP193vr+JzQ1PBE3O1Nu65n+MbxAdUtPAuSJTldJ1Up4mYR1q8+WZNLu+ S67gZKj2ZpQKA1UZOkBa5KLYcm8vLgek4C+HaZyLgqEU4DkBqxJlSREHojYaZ7WCAs544i6aqPFOL 0Pj8JH93lq52jxLFLVpenSAvgKgQTC5aPGF5KPaEzoQe6OLAgl4bRjfUO+fnyXDb/xwrDig/t7ANI hT1wKQLFRnUPyPtwVI3Z6lCDGGydZ1hh2dbBM5zDrj7zZ02/8wVWTHyQa05M4mEhRSbJSoQFFS+Cq 7UC6EJ6Bc4yP6qxiGuYA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwzmn-005tTr-Tq; Fri, 03 Jun 2022 05:23:50 +0000 Received: from mail-oi1-x22d.google.com ([2607:f8b0:4864:20::22d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwzmk-005tSW-D3 for linux-arm-kernel@lists.infradead.org; Fri, 03 Jun 2022 05:23:47 +0000 Received: by mail-oi1-x22d.google.com with SMTP id s188so9184640oie.4 for ; Thu, 02 Jun 2022 22:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WzoFXntAxDsmUFhrpSN0lydvB+GY7yOTwcwlnFeu8rY=; b=cDX1z3L55FaZQ0li/2NABGuvZQyvjAqV+mY2GlCyFa5u97/2e33Jq96U0qmoLghctm 5GP1pn3Im95P2noRUSsP4jMGfKhVGu/wtPGSZcVLj2kkpTlQuFl5kBNQD/OZ83qAuU6g 0itfRy6UbiuNxrzOIdfKQebbdyu07JlOyc4y7Q5kSQRaOgNbU9vc0avrBsuMOkgXQ+S4 yEA0gyK51HTDVMj/ih70oU7ulvB3yWtlYfg2RRAg7fYWss0yZ3U93FQZKEouD20Zh417 +UNSKGp7HfokN03K4UEzG7nVgpMjkENcfzRrGddIaKJZ8xAC6DmA9fRLiBh/L+ZPF6ED G9gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WzoFXntAxDsmUFhrpSN0lydvB+GY7yOTwcwlnFeu8rY=; b=w5r+kJXdqOcwA5i1oxgzSMwRxr2C67h/AEJGwJ+P9XvlFuKKNcbwc/VSBRfjQ3e/Cv LZeAbLLGiW9abtcAK0/yWwEGH0VMN+Kd+yBPnm4D8vm0HU/4Y/xzf8cZTvqra/DUjSaT pF5aQ6+Jx6r9nd9oPeL0V7BGYhi7u1iSGIhNhTsM6vcbe/O9l2cG2QCtfyQAxqSzL4jG 5qipSrM5MAmadOYXARROUYCXUv764w0V2LONeRZsmn+vBH2NkCPSXP1EAccnt7ivZxoX ffeR9Jck90QTIH/ZLg/Qgmj0/zDrCXrO4npbULJnotYwzwH0c6VBOzJFkAMvSlUwbyNn k+aQ== X-Gm-Message-State: AOAM531qY+lBlV+L/MhZ+n6nqhajuYdD1KuJ+Am7ct/VUhujEIEkHLIH vdDKQCMdZvVZ0DHa9xRgde4Mcz/4s543pZVMkr6EIGUEuBf16A== X-Google-Smtp-Source: ABdhPJzJos2xkVCVqdPnVrVWhwf2C8SCrcNh90O1+X0s17dXtFigyJz4zZMj4J/ZSP/5Utgr5FClDToyr9C7HgI430I= X-Received: by 2002:a05:6808:144d:b0:32b:7fbc:943d with SMTP id x13-20020a056808144d00b0032b7fbc943dmr20056912oiv.107.1654233821610; Thu, 02 Jun 2022 22:23:41 -0700 (PDT) MIME-Version: 1.0 References: <20220528113829.1043361-1-maz@kernel.org> <20220528113829.1043361-4-maz@kernel.org> In-Reply-To: <20220528113829.1043361-4-maz@kernel.org> From: Reiji Watanabe Date: Thu, 2 Jun 2022 22:23:25 -0700 Message-ID: Subject: Re: [PATCH 03/18] KVM: arm64: Drop FP_FOREIGN_STATE from the hypervisor code To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Linux ARM , kernel-team@android.com, Will Deacon , Mark Brown X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220602_222346_503876_2FABAC98 X-CRM114-Status: GOOD ( 26.24 ) 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 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) Thanks, Reiji _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel