Message ID | 20230216160012.272345-4-kristina.martsenko@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp381718wrn; Thu, 16 Feb 2023 08:03:31 -0800 (PST) X-Google-Smtp-Source: AK7set8GMgQg18jxHd0h0cAB29aIzauw9lO2ewIkp6CWSu0acwFuGCgK5t2vJcmlr/j5P7EXU9j0 X-Received: by 2002:a17:906:dfd2:b0:877:7113:71f3 with SMTP id jt18-20020a170906dfd200b00877711371f3mr6456855ejc.25.1676563411395; Thu, 16 Feb 2023 08:03:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676563411; cv=none; d=google.com; s=arc-20160816; b=MeHHeOaPW3XHBfMH+oXsMi/I5fUeMjt2dqe54eppWFip4imjt9Nsfcpb76uH2rpAUg 1NXmO8Nmzaj/0d/D49J4cf44UWVWtYsh5aJ6UnFVidzCvPRDwaeB6wlAeP+h6Ajahwmn A7Aj07BXwet/eHCeh8cBpUpduMNGad/YVp/Wz94/aNsk4k9osLjBarwFwQdSYF4SPfOy TKJdO8X8348qxRhbR8XKocQxRSM9cYeMCJGVvgNoE6zew9cHH81cujLTA+UJawH87Czr OUClsWlpFShgbDRL7XG1MI/3eJQf0xlHAgcHvzh0EK1YiD4bBB5IfMzH4Uz0Zln58Uw0 dHqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=dNrWzBmmZoGSGJu7G5pgcJxjy1NPJsEuJ+j+h0gX7Vo=; b=pKd3ImWz2qJcJnUwCKgRtaqZd9zEKjbFvGgvdf6pZFV3ISGohqghPpOY+tIbqnDenK rrbzZ02wRfpnxCOJi38HWZvQkaczNnFIHg1OcvBSJYajfYa+dVKqrngrnyAQjgkmVBf5 UGexsIMU32MpJCLSLmXx0E4rdCajJxciSOQiSA44dCXHLHeKED68QFZNzI6mUObAAOm2 3IP0+0B286zpj/4n91kI5788cJ4yDw3gPP+YAlFUV/EOxq/OhPa5spMJ9uP3EJB0QORR GkdsIU0PlVt+N6HC9ZpBJCcn3qJClnE0+0q1rHBX0cS94yYC9OQK1TUOT18K+dRtfp+W 6XpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cq19-20020a170906d51300b008b14d614ed6si1880365ejc.472.2023.02.16.08.03.07; Thu, 16 Feb 2023 08:03:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229762AbjBPQBp (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Thu, 16 Feb 2023 11:01:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229672AbjBPQBl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Feb 2023 11:01:41 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4A39454548 for <linux-kernel@vger.kernel.org>; Thu, 16 Feb 2023 08:01:38 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 127B91042; Thu, 16 Feb 2023 08:02:21 -0800 (PST) Received: from e126864.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 37A003F881; Thu, 16 Feb 2023 08:01:35 -0800 (PST) From: Kristina Martsenko <kristina.martsenko@arm.com> To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Oliver Upton <oliver.upton@linux.dev>, James Morse <james.morse@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Zenghui Yu <yuzenghui@huawei.com>, Mark Rutland <mark.rutland@arm.com>, Mark Brown <broonie@kernel.org>, Luis Machado <luis.machado@arm.com>, Vladimir Murzin <vladimir.murzin@arm.com>, linux-kernel@vger.kernel.org Subject: [PATCH 03/10] KVM: arm64: switch HCRX_EL2 between host and guest Date: Thu, 16 Feb 2023 16:00:05 +0000 Message-Id: <20230216160012.272345-4-kristina.martsenko@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230216160012.272345-1-kristina.martsenko@arm.com> References: <20230216160012.272345-1-kristina.martsenko@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758004155237141114?= X-GMAIL-MSGID: =?utf-8?q?1758004155237141114?= |
Series |
arm64: support Armv8.8 memcpy instructions in userspace
|
|
Commit Message
Kristina Martsenko
Feb. 16, 2023, 4 p.m. UTC
Switch the HCRX_EL2 register between host and guest configurations, in
order to enable different features in the host and guest.
Note that the guest flags are only set if all CPUs have HCRX_EL2.
Asymmetric systems where only some CPUs have HCRX_EL2 are not supported
and will result in guests running with the host flags set (and a "SANITY
CHECK" warning printed for the host).
After this change, SMPME is no longer set for guests, which should have
no effect as SME is currently disabled for guests.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
I wasn't sure what to do about asymmetric systems. It seems a bit
fragile, maybe someone has a better idea?
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kvm/hyp/include/hyp/switch.h | 6 ++++++
2 files changed, 7 insertions(+)
Comments
On Thu, Feb 16, 2023 at 04:00:05PM +0000, Kristina Martsenko wrote: > After this change, SMPME is no longer set for guests, which should have > no effect as SME is currently disabled for guests. SMPME is mainly set for the benefit of any future guests, it is used to turn off SME priorities for guests. While it's true that we don't have any guests support yet it's there as safety to ensure we don't forget to enable it later on or something otherwise goes wrong. We don't need priority mapping on the host since we don't have any priority mapping support at all, and it's difficult to see a reason why we would want to remap our own priorities in the host.
On Thu, 16 Feb 2023 16:00:05 +0000, Kristina Martsenko <kristina.martsenko@arm.com> wrote: > > Switch the HCRX_EL2 register between host and guest configurations, in > order to enable different features in the host and guest. > > Note that the guest flags are only set if all CPUs have HCRX_EL2. > Asymmetric systems where only some CPUs have HCRX_EL2 are not supported > and will result in guests running with the host flags set (and a "SANITY > CHECK" warning printed for the host). > > After this change, SMPME is no longer set for guests, which should have > no effect as SME is currently disabled for guests. Why not preserve the behaviour by propagating the flag into the guest setup? > > Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> > --- > > I wasn't sure what to do about asymmetric systems. It seems a bit > fragile, maybe someone has a better idea? I would simply prevent these CPUs from booting if they come after a primary CPU that has the feature. These hypothetical asymmetric setups put a huge complexity on the kernel, and I'm worried that we're just giving implementers too much freedom. If someone comes up with that sort of stuff, they can write the patches themselves... Or do you know of any braindead setup involving an asymmetric FEAT_HCX implementation? Thanks, M.
On 16/02/2023 16:20, Mark Brown wrote: > On Thu, Feb 16, 2023 at 04:00:05PM +0000, Kristina Martsenko wrote: > >> After this change, SMPME is no longer set for guests, which should have >> no effect as SME is currently disabled for guests. > > SMPME is mainly set for the benefit of any future guests, it is > used to turn off SME priorities for guests. While it's true that > we don't have any guests support yet it's there as safety to > ensure we don't forget to enable it later on or something > otherwise goes wrong. We don't need priority mapping on the host > since we don't have any priority mapping support at all, and it's > difficult to see a reason why we would want to remap our own > priorities in the host. That makes sense. I'll fix this in v2 so that priority mapping is enabled for guests and disabled for the host. Thanks, Kristina
On 16/02/2023 16:35, Marc Zyngier wrote: > On Thu, 16 Feb 2023 16:00:05 +0000, > Kristina Martsenko <kristina.martsenko@arm.com> wrote: >> >> Switch the HCRX_EL2 register between host and guest configurations, in >> order to enable different features in the host and guest. >> >> Note that the guest flags are only set if all CPUs have HCRX_EL2. >> Asymmetric systems where only some CPUs have HCRX_EL2 are not supported >> and will result in guests running with the host flags set (and a "SANITY >> CHECK" warning printed for the host). >> >> After this change, SMPME is no longer set for guests, which should have >> no effect as SME is currently disabled for guests. > > Why not preserve the behaviour by propagating the flag into the guest > setup? I thought it made more sense to disable SMPME given that SME is not supported in guests yet (and that the existing behavior was just a side effect of not having support for switching HCRX), but I'd misunderstood what SMPME is for, and following Mark's explanation I'll actually preserve the behavior for guests, but now disable SMPME for the host instead (as SME priority mapping has no benefit in the host and is not intended to be used there). > >> >> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> >> --- >> >> I wasn't sure what to do about asymmetric systems. It seems a bit >> fragile, maybe someone has a better idea? > > I would simply prevent these CPUs from booting if they come after a > primary CPU that has the feature. I considered that but the concern I heard was that since virtualization is an optional feature then people may still want to use the system without it. > These hypothetical asymmetric setups > put a huge complexity on the kernel, and I'm worried that we're just > giving implementers too much freedom. > > If someone comes up with that sort of stuff, they can write the > patches themselves... I'll make it panic on a mismatch for now and it can be revisited in the future if such a system actually appears (which does seem very unlikely). > Or do you know of any braindead setup involving > an asymmetric FEAT_HCX implementation? Nope don't know of one, it was just hypothetical. Thanks, Kristina
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index caa31f4ab1cd..cd8dd307aaba 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@ -93,6 +93,7 @@ #define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC) #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H) +#define HCRX_GUEST_FLAGS 0 #define HCRX_HOST_FLAGS (HCRX_EL2_SMPME) /* TCR_EL2 Registers bits */ diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h index 07d37ff88a3f..a1bf2d879db5 100644 --- a/arch/arm64/kvm/hyp/include/hyp/switch.h +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h @@ -129,6 +129,9 @@ static inline void ___activate_traps(struct kvm_vcpu *vcpu) if (cpus_have_final_cap(ARM64_HAS_RAS_EXTN) && (hcr & HCR_VSE)) write_sysreg_s(vcpu->arch.vsesr_el2, SYS_VSESR_EL2); + + if (cpus_have_final_cap(ARM64_HAS_HCX)) + write_sysreg_s(HCRX_GUEST_FLAGS, SYS_HCRX_EL2); } static inline void ___deactivate_traps(struct kvm_vcpu *vcpu) @@ -143,6 +146,9 @@ static inline void ___deactivate_traps(struct kvm_vcpu *vcpu) vcpu->arch.hcr_el2 &= ~HCR_VSE; vcpu->arch.hcr_el2 |= read_sysreg(hcr_el2) & HCR_VSE; } + + if (cpus_have_final_cap(ARM64_HAS_HCX)) + write_sysreg_s(HCRX_HOST_FLAGS, SYS_HCRX_EL2); } static inline bool __populate_fault_info(struct kvm_vcpu *vcpu)