Message ID | 20230216160012.272345-5-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 s9csp381900wrn; Thu, 16 Feb 2023 08:03:47 -0800 (PST) X-Google-Smtp-Source: AK7set9tocH3mxZJ+Gw+KCUoah1gs5xaHEQcWAgIQOxExIZN0JOvQOEKiHLMojSiUOmdrVsoUYqe X-Received: by 2002:a17:907:a42a:b0:8b1:730b:a296 with SMTP id sg42-20020a170907a42a00b008b1730ba296mr1973701ejc.15.1676563427134; Thu, 16 Feb 2023 08:03:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676563427; cv=none; d=google.com; s=arc-20160816; b=RWvWIb5LK/UWkEiLSN43rx2NIBJpwZn79qIKSEJuBn5f2rPkT3DlFfnY88HUdVMR0x +1ZAOPgozJjkvDhyl0/tuh/LOEQhj1cl5ZDOP4ZiS1+Cg986vxJWPrVG48y3PG9po3a6 GENT8tdWtGg9H9JE9vm6ITMD9f46fbA8ie0uahQx+iUs0wo2mPPoxK041XjohBkmGupg mbX4JCMNXk1VYajMBmG/wTyl3yFDKdAft1DHv076UB6HDzg1G2B04jAhY4KLQYMxVXfW v/4e4aeGyYW52xtBV5bz3J7+uNNe6/ym9lt48wGsnxakUo77XSTVrZwRccasOGCtbb82 aJIA== 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=SgtbRMfdu5mp33Qy+rwd39uorsnF+c3KKGd2Sg7VTlI=; b=r4aENq1cYQoYIpVbqrD3/hMYXy+12Z6hheHM10xdX6MPrLYHLLftxpOTBPYn5Tje/8 IbdGEpRxzGxP8Ra6WtKBFWowRXXnm1NA3RIqtc1dkjD8RnvaxARGcsi3cLY6XhBFgxwf EnJPu6lylerExJcn4qyOzXhX8/F7KupKSx+opX/pnrOLe8UK6V1jInBVXubOKJSu8mph uPr2YxRgv/twP0z+6rZNZfKTuchYWm6bH/VAOmpaJuPBj3UTUDhZx53DY0hfgy+ChOpA ZUuQzwpnTwfrJt7YxTDugdqZzM9FKtjECDQ8KpmPzcPE2d3YNww4T/AydHN4Q6Y/yL5E PgCQ== 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 ep11-20020a1709069b4b00b008786508e28csi2018494ejc.1005.2023.02.16.08.03.08; Thu, 16 Feb 2023 08:03:47 -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 S229929AbjBPQBz (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Thu, 16 Feb 2023 11:01:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229608AbjBPQBv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Feb 2023 11:01:51 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D568D59B78 for <linux-kernel@vger.kernel.org>; Thu, 16 Feb 2023 08:01:42 -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 432C5113E; Thu, 16 Feb 2023 08:02:25 -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 5D02B3F881; Thu, 16 Feb 2023 08:01:39 -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 04/10] arm64: mops: document boot requirements for MOPS Date: Thu, 16 Feb 2023 16:00:06 +0000 Message-Id: <20230216160012.272345-5-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?1758004171840802605?= X-GMAIL-MSGID: =?utf-8?q?1758004171840802605?= |
Series |
arm64: support Armv8.8 memcpy instructions in userspace
|
|
Commit Message
Kristina Martsenko
Feb. 16, 2023, 4 p.m. UTC
FEAT_MOPS introduces new instructions, we require that these
instructions not execute as UNDEFINED when we identify that the feature
is supported. Additionally, the instructions may generate a Memory Copy
or Memory Set exception, we require that the exception be taken to EL1
in case EL2 is not able to correctly handle it.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
Documentation/arm64/booting.rst | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
On Thu, Feb 16, 2023 at 04:00:06PM +0000, Kristina Martsenko wrote: > + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): > + > + - If the kernel is entered at EL1 and EL2 is present: > + > + - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1. > + > + - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b0. Regarding MCE2, does EL1 actually care if EL2 wants to handle all the memcpy/memset exceptions? There may even be a valid case to do this at EL2 if you run a guest that uses these instructions but has no clue on how to deal with the specific exception like WrongOption.
On 17/03/2023 15:07, Catalin Marinas wrote: > On Thu, Feb 16, 2023 at 04:00:06PM +0000, Kristina Martsenko wrote: >> + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): >> + >> + - If the kernel is entered at EL1 and EL2 is present: >> + >> + - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1. >> + >> + - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b0. > > Regarding MCE2, does EL1 actually care if EL2 wants to handle all the > memcpy/memset exceptions? No, EL1 does not need to handle the exceptions itself, but I don't see any current use case for allowing EL2 to handle it. If it was allowed, I think booting.txt would need to specify exactly what Linux expects EL2 to do if MCE2 is set (eg, that EL2 handles the exception by reformatting registers, modifying single step state, etc). > There may even be a valid case to do this at > EL2 if you run a guest that uses these instructions but has no clue on > how to deal with the specific exception like WrongOption. Not sure I follow - this series adds the exception handling, so how can a Linux guest not know how to handle the exception? Or do you mean that there may be times when EL1 can't take the exception but EL2 may move it to another CPU, and so EL2 would need to handle the exception? I'm not sure if Linux ever uses mops instructions at times like that. Note that this series does not add support for mops in guests yet. I think booting.txt can be updated when that support is added. Thanks, Kristina
On Fri, Mar 24, 2023 at 01:00:43AM +0000, Kristina Martsenko wrote: > On 17/03/2023 15:07, Catalin Marinas wrote: > > On Thu, Feb 16, 2023 at 04:00:06PM +0000, Kristina Martsenko wrote: > >> + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): > >> + > >> + - If the kernel is entered at EL1 and EL2 is present: > >> + > >> + - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1. > >> + > >> + - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b0. > > > > Regarding MCE2, does EL1 actually care if EL2 wants to handle all the > > memcpy/memset exceptions? > > No, EL1 does not need to handle the exceptions itself, but I don't see any > current use case for allowing EL2 to handle it. > > If it was allowed, I think booting.txt would need to specify exactly what Linux > expects EL2 to do if MCE2 is set (eg, that EL2 handles the exception by > reformatting registers, modifying single step state, etc). What I meant is that an EL1 kernel shouldn't care if MCE2 is 0 or 1. We could clarify that if set to 1, it is expected that the hypervisor handles the memory copy/set exceptions accordingly. > > There may even be a valid case to do this at > > EL2 if you run a guest that uses these instructions but has no clue on > > how to deal with the specific exception like WrongOption. > > Not sure I follow - this series adds the exception handling, so how can a Linux > guest not know how to handle the exception? The guest may not always be Linux (e.g. some microkernel) and may not expect the hardware implementation to change underneath. > Or do you mean that there may be times when EL1 can't take the exception but > EL2 may move it to another CPU, and so EL2 would need to handle the exception? I haven't thought of this but it's actually a good point. Are there any cases where Linux can't handle a memcpy exception? I guess we need to be careful with taking such exception in an atomic context (e.g. no rescheduling on the return path). > I'm not sure if Linux ever uses mops instructions at times like that. The compiler may generate a memcpy() call by simply assigning a structure to another. So we can't control where those instructions are used. > Note that this series does not add support for mops in guests yet. You mean there's no KVM support. But Linux may be run under a different hypervisor (e.g. Hyper-V) as a guest. > I think booting.txt can be updated when that support is added. In booting.txt, when you say the kernel entered at EL1, it implies that it may be run as a guest under a random hypervisor. So maybe we should detail the MCE2 requirement a bit, saying that it can be either 0 or 1 but, for the latter, the hypervisor must handle the corresponding exceptions.
On 04/04/2023 11:50, Catalin Marinas wrote: > On Fri, Mar 24, 2023 at 01:00:43AM +0000, Kristina Martsenko wrote: >> On 17/03/2023 15:07, Catalin Marinas wrote: >>> On Thu, Feb 16, 2023 at 04:00:06PM +0000, Kristina Martsenko wrote: >>>> + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): >>>> + >>>> + - If the kernel is entered at EL1 and EL2 is present: >>>> + >>>> + - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1. >>>> + >>>> + - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b0. >>> >>> Regarding MCE2, does EL1 actually care if EL2 wants to handle all the >>> memcpy/memset exceptions? >> >> Note that this series does not add support for mops in guests yet. > > You mean there's no KVM support. But Linux may be run under a different > hypervisor (e.g. Hyper-V) as a guest. > >> I think booting.txt can be updated when that support is added. > > In booting.txt, when you say the kernel entered at EL1, it implies that > it may be run as a guest under a random hypervisor. > > So maybe we should detail the MCE2 requirement a bit, saying that it can > be either 0 or 1 but, for the latter, the hypervisor must handle the > corresponding exceptions. That makes sense. I was going to add this, but then realized that MCE2 only traps memcpy exceptions from EL1, not EL0, so it does not have any effect with this series. So I think we can just drop the MCE2 requirement entirely for now and specify the requirement later when we add memcpy instructions into the kernel itself. Thanks, Kristina
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index ffeccdd6bdac..f3913ee94c42 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -379,6 +379,14 @@ Before jumping into the kernel, the following conditions must be met: - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1. + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): + + - If the kernel is entered at EL1 and EL2 is present: + + - HCRX_EL2.MSCEn (bit 11) must be initialised to 0b1. + + - HCRX_EL2.MCE2 (bit 10) must be initialised to 0b0. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. Where the values documented