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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C69A1C4167B for ; Mon, 11 Dec 2023 17:30:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B2D66B0187; Mon, 11 Dec 2023 12:30:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 389886B0188; Mon, 11 Dec 2023 12:30:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 250EE6B0189; Mon, 11 Dec 2023 12:30:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 143046B0187 for ; Mon, 11 Dec 2023 12:30:02 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BA911A06C5 for ; Mon, 11 Dec 2023 17:30:01 +0000 (UTC) X-FDA: 81555225402.16.D41187E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 929B040012 for ; Mon, 11 Dec 2023 17:29:58 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LIhraVqy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of robh@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=robh@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702315798; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yXYkUw7aa01q2R7YDsyxDhXUb3UlEceRpci7IBlKnLE=; b=BLL/wXeACNWmTnWhGJU1fDN5QpEr7F2Sdjg9tJTtaTSluRtkX43/WvNx95UN/HmhX/kLB8 ODfYTyGpobMOneDGKlWR6APF4et6EHwyaw2HLYeKxcI2a0Edj6iG0OcTfXJAhDxGA98D9e QEVRzXwKLPzRQqQP02KZVxvwXctl044= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LIhraVqy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of robh@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=robh@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702315798; a=rsa-sha256; cv=none; b=hF7sMu3yqd0yA9meZTHrizXQFVd1ikY7XaCpfyjHzVPbVFeIHPX6z+hjaOoUsUQNPSytMF 45D0cIxXQxthu1E6o5OlsCMxebAandxfxG601ZxOl3qJKVCUT/ObtthFCpwcPVsqQGahhl 56YsAeqhO9Cvg9D6MHW6h2uZ0HbuA78= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8665B614B7 for ; Mon, 11 Dec 2023 17:29:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC67BC433A9 for ; Mon, 11 Dec 2023 17:29:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702315795; bh=VP6rxIE0YrbcOG/9wnq9cB6kaypzUe7LOgu57Kw03yM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LIhraVqyQdSfQe228mHwkdXxGCCkLJRry0OfP50RDcmYcgm8HYl+sN3lFgIsGHDkK qFO1jpKRk+4TV2pPCWzuXXcpy1Dk746QciwjtOX8bcBqP8nO8fuWCbncIY5C/+NF+v cPzN+QScdCx4rbHwHJM108XK0PEj0HkcGBUCffokZCX7WvCk8kP7BT59+On5Hj1Cs0 Cc9NwAaOcBbcPNEJjn1lNYgvYedpyeWHkuK3FGA02cVw5xOGAItnRvZJVw9oT4a2pL GnRi3dIGBh7BQ9YkMKVpbbCkn0ysVsBEklPtgsOXrkpxfjYzztn9cXcSNZ7aGNhQge 25LiqNlUEnFvA== Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-50c222a022dso4997258e87.1 for ; Mon, 11 Dec 2023 09:29:55 -0800 (PST) X-Gm-Message-State: AOJu0YydvS2Rzzs9YQ8/hWghUlaNV9eC06mgvp7IRlf/jG1tjJoW5+MW gQjdboqFZlobIdSE6fXrDROQ+ZbOu2NO0N4iAg== X-Google-Smtp-Source: AGHT+IGf9GxCgHbSaCR9ChlHwIzcYeJN/o9beG+fFS/Wj2+MXjJAqODSxU5em7xHCQ26rKUjit1wlHMa263dNGOiUjs= X-Received: by 2002:ac2:42c3:0:b0:50b:efd4:1475 with SMTP id n3-20020ac242c3000000b0050befd41475mr1861829lfl.9.1702315793752; Mon, 11 Dec 2023 09:29:53 -0800 (PST) MIME-Version: 1.0 References: <20231119165721.9849-1-alexandru.elisei@arm.com> <20231119165721.9849-12-alexandru.elisei@arm.com> In-Reply-To: <20231119165721.9849-12-alexandru.elisei@arm.com> From: Rob Herring Date: Mon, 11 Dec 2023 11:29:40 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC v2 11/27] arm64: mte: Reserve tag storage memory To: Alexandru Elisei Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, anshuman.khandual@arm.com, vincenzo.frascino@arm.com, david@redhat.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 929B040012 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 3jmyzsuqnnhrzszqqfkxnm8f64ymqaqj X-HE-Tag: 1702315798-37707 X-HE-Meta: U2FsdGVkX18/f2if2ZEVwbbyUhBelvmOEbjDORVM1TzbxWjNL4s9KKQdpshGWW6+tWg/Yjha1OsJGlWJdUwkNGLO2lXOYfhw63038sncGoDOqOLsmF7o4DlVsqFe+WKtVhd/HQbtwh7rjPFJ6fPiRw4x19BBZ7mNyJ/ChtEquCq9I2cDB0DRY/Ye9xpgIKmE2GdpSEZNFd3d/yj+apv5rIFacTPB9jPz3OOgQExoPMA3V0xt1sQC0SprY98x4n8W22Xfpdl4GvuiLAuVAad0e/rp0cNue6AVYI6iIHtwKKqs3HT/gghNxI231dghqxcACtNAXrrdZWW/Wl0p3iE4g+PKE1hZfGSuak6RLcV/D9LPjWZX+iCH12vGuQHGQmwm+ufFrL4/OXit/gIlf9Xw+X7pNMOatxXRGycYD4tE6NLateiZtEcT7g8jEUhq6JEwL2NPPEX2OmzAuc+6ncs+bD1E1reuWCpUgDyocrh9B09dv+saDiGyBckbQtGkOE2OBOVgu4gbehX5AkHo1px3E2XwpinaCycjoNy3perT1WqVL9af+UuMTvO6iw8XTUdWwpmCALKi8mHrvR2Vu2f6d3jBajI+E4avUIMw5I7CvhFzcOSUP1HxlgnBR8LM8X8FuBZSMjsVahVBuVO9C0VxHkLUOSYGkpnsmcaivJy+QknHpLFVafvzFAXi54LDsDxQLKPqRq0LObec8YmFeEqkadQqwL/NmSJrBpmJuhioAapzr6NScrr1EzleSjGAGtID6vx8p5M+2Qxo3DholtN5A/p1fOUY2tblI5R44szVGx9cjQQLcLqxtukcsNst13CkqrrRFIu+0cwqZkMmOnWdVLcsEzFwRqLlugKpgprtyCMvUlwXwe6LRE1qBjZv79N6Bzjxa+3ueTpE4iAMi0UzxwtMK83ze0rgUsDYj+JVqmcKM2HgO5p9j3Ui3xzetGppDjMcg7c33as2cbaL1GV ju9Aa0ki NZTN4F3biF/bOoyQttbpC3vBpc1WjqiF1LLhhHhseQ7COyGZgyWv9YOKC7jqoo2BMZ+gKF/fN68iU8OTxVorPf8QgOCJrontLKlQkoHMVsOjdt7bPd7mU918WkKEJJVr3Rc41XhevZtlD7kcHXDCzfesjoncn4feIu9B6DtgU5jSVv+5GufZNjivlMVhJRAUplveU5QqB7wrVrjmtkxNakSSuxzvO3F9HUQRWs2yDWrnGoXunVwsZsNz8oTM+akjEVgoefuY53YH4Li8RRuXp2CTNow== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, Nov 19, 2023 at 10:59=E2=80=AFAM Alexandru Elisei wrote: > > Allow the kernel to get the size and location of the MTE tag storage > regions from the DTB. This memory is marked as reserved for now. > > The DTB node for the tag storage region is defined as: > > tags0: tag-storage@8f8000000 { > compatible =3D "arm,mte-tag-storage"; > reg =3D <0x08 0xf8000000 0x00 0x4000000>; > block-size =3D <0x1000>; > memory =3D <&memory0>; // Associated tagged memory nod= e > }; I skimmed thru the discussion some. If this memory range is within main RAM, then it definitely belongs in /reserved-memory. You need a binding for this too. > The tag storage region represents the largest contiguous memory region th= at > holds all the tags for the associated contiguous memory region which can = be > tagged. For example, for a 32GB contiguous tagged memory the correspondin= g > tag storage region is 1GB of contiguous memory, not two adjacent 512M of > tag storage memory. > > "block-size" represents the minimum multiple of 4K of tag storage where a= ll > the tags stored in the block correspond to a contiguous memory region. Th= is > is needed for platforms where the memory controller interleaves tag write= s > to memory. For example, if the memory controller interleaves tag writes f= or > 256KB of contiguous memory across 8K of tag storage (2-way interleave), > then the correct value for "block-size" is 0x2000. This value is a hardwa= re > property, independent of the selected kernel page size. > > Signed-off-by: Alexandru Elisei > --- > arch/arm64/Kconfig | 12 ++ > arch/arm64/include/asm/mte_tag_storage.h | 15 ++ > arch/arm64/kernel/Makefile | 1 + > arch/arm64/kernel/mte_tag_storage.c | 256 +++++++++++++++++++++++ > arch/arm64/kernel/setup.c | 7 + > 5 files changed, 291 insertions(+) > create mode 100644 arch/arm64/include/asm/mte_tag_storage.h > create mode 100644 arch/arm64/kernel/mte_tag_storage.c > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 7b071a00425d..fe8276fdc7a8 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -2062,6 +2062,18 @@ config ARM64_MTE > > Documentation/arch/arm64/memory-tagging-extension.rst. > > +if ARM64_MTE > +config ARM64_MTE_TAG_STORAGE > + bool "Dynamic MTE tag storage management" > + help > + Adds support for dynamic management of the memory used by the h= ardware > + for storing MTE tags. This memory, unlike normal memory, cannot= be > + tagged. When it is used to store tags for another memory locati= on it > + cannot be used for any type of allocation. > + > + If unsure, say N > +endif # ARM64_MTE > + > endmenu # "ARMv8.5 architectural features" > > menu "ARMv8.7 architectural features" > diff --git a/arch/arm64/include/asm/mte_tag_storage.h b/arch/arm64/includ= e/asm/mte_tag_storage.h > new file mode 100644 > index 000000000000..8f86c4f9a7c3 > --- /dev/null > +++ b/arch/arm64/include/asm/mte_tag_storage.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2023 ARM Ltd. > + */ > +#ifndef __ASM_MTE_TAG_STORAGE_H > +#define __ASM_MTE_TAG_STORAGE_H > + > +#ifdef CONFIG_ARM64_MTE_TAG_STORAGE > +void mte_tag_storage_init(void); > +#else > +static inline void mte_tag_storage_init(void) > +{ > +} > +#endif /* CONFIG_ARM64_MTE_TAG_STORAGE */ > +#endif /* __ASM_MTE_TAG_STORAGE_H */ > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile > index d95b3d6b471a..5f031bf9f8f1 100644 > --- a/arch/arm64/kernel/Makefile > +++ b/arch/arm64/kernel/Makefile > @@ -70,6 +70,7 @@ obj-$(CONFIG_CRASH_CORE) +=3D crash_core.o > obj-$(CONFIG_ARM_SDE_INTERFACE) +=3D sdei.o > obj-$(CONFIG_ARM64_PTR_AUTH) +=3D pointer_auth.o > obj-$(CONFIG_ARM64_MTE) +=3D mte.o > +obj-$(CONFIG_ARM64_MTE_TAG_STORAGE) +=3D mte_tag_storage.o > obj-y +=3D vdso-wrap.o > obj-$(CONFIG_COMPAT_VDSO) +=3D vdso32-wrap.o > obj-$(CONFIG_UNWIND_PATCH_PAC_INTO_SCS) +=3D patch-scs.o > diff --git a/arch/arm64/kernel/mte_tag_storage.c b/arch/arm64/kernel/mte_= tag_storage.c > new file mode 100644 > index 000000000000..fa6267ef8392 > --- /dev/null > +++ b/arch/arm64/kernel/mte_tag_storage.c > @@ -0,0 +1,256 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Support for dynamic tag storage. > + * > + * Copyright (C) 2023 ARM Ltd. > + */ > + > +#include > +#include > +#include You probably don't need this header. If you depend on what it implicitly includes, then that will now break in linux-next. > +#include > +#include > +#include > +#include > + > +#include > + > +struct tag_region { > + struct range mem_range; /* Memory associated with the tag storage= , in PFNs. */ > + struct range tag_range; /* Tag storage memory, in PFNs. */ > + u32 block_size; /* Tag block size, in pages. */ > +}; > + > +#define MAX_TAG_REGIONS 32 > + > +static struct tag_region tag_regions[MAX_TAG_REGIONS]; > +static int num_tag_regions; > + > +static int __init tag_storage_of_flat_get_range(unsigned long node, cons= t __be32 *reg, > + int reg_len, struct range= *range) > +{ > + int addr_cells =3D dt_root_addr_cells; > + int size_cells =3D dt_root_size_cells; > + u64 size; > + > + if (reg_len / 4 > addr_cells + size_cells) > + return -EINVAL; > + > + range->start =3D PHYS_PFN(of_read_number(reg, addr_cells)); > + size =3D PHYS_PFN(of_read_number(reg + addr_cells, size_cells)); > + if (size =3D=3D 0) { > + pr_err("Invalid node"); > + return -EINVAL; > + } > + range->end =3D range->start + size - 1; We have a function to read (and translate which you forgot) addresses. Add what's missing rather than open code your own. > + > + return 0; > +} > + > +static int __init tag_storage_of_flat_get_tag_range(unsigned long node, > + struct range *tag_ran= ge) > +{ > + const __be32 *reg; > + int reg_len; > + > + reg =3D of_get_flat_dt_prop(node, "reg", ®_len); > + if (reg =3D=3D NULL) { > + pr_err("Invalid metadata node"); > + return -EINVAL; > + } > + > + return tag_storage_of_flat_get_range(node, reg, reg_len, tag_rang= e); > +} > + > +static int __init tag_storage_of_flat_get_memory_range(unsigned long nod= e, struct range *mem) > +{ > + const __be32 *reg; > + int reg_len; > + > + reg =3D of_get_flat_dt_prop(node, "linux,usable-memory", ®_len= ); > + if (reg =3D=3D NULL) > + reg =3D of_get_flat_dt_prop(node, "reg", ®_len); > + > + if (reg =3D=3D NULL) { > + pr_err("Invalid memory node"); > + return -EINVAL; > + } > + > + return tag_storage_of_flat_get_range(node, reg, reg_len, mem); > +} > + > +struct find_memory_node_arg { > + unsigned long node; > + u32 phandle; > +}; > + > +static int __init fdt_find_memory_node(unsigned long node, const char *u= name, > + int depth, void *data) > +{ > + const char *type =3D of_get_flat_dt_prop(node, "device_type", NUL= L); > + struct find_memory_node_arg *arg =3D data; > + > + if (depth !=3D 1 || !type || strcmp(type, "memory") !=3D 0) > + return 0; > + > + if (of_get_flat_dt_phandle(node) =3D=3D arg->phandle) { > + arg->node =3D node; > + return 1; > + } > + > + return 0; > +} > + > +static int __init tag_storage_get_memory_node(unsigned long tag_node, un= signed long *mem_node) > +{ > + struct find_memory_node_arg arg =3D { 0 }; > + const __be32 *memory_prop; > + u32 mem_phandle; > + int ret, reg_len; > + > + memory_prop =3D of_get_flat_dt_prop(tag_node, "memory", ®_len)= ; > + if (!memory_prop) { > + pr_err("Missing 'memory' property in the tag storage node= "); > + return -EINVAL; > + } > + > + mem_phandle =3D be32_to_cpup(memory_prop); > + arg.phandle =3D mem_phandle; > + > + ret =3D of_scan_flat_dt(fdt_find_memory_node, &arg); Do not use of_scan_flat_dt. It is a relic predating libfdt which can get a node by phandle directly. > + if (ret !=3D 1) { > + pr_err("Associated memory node not found"); > + return -EINVAL; > + } > + > + *mem_node =3D arg.node; > + > + return 0; > +} > + > +static int __init tag_storage_of_flat_read_u32(unsigned long node, const= char *propname, > + u32 *retval) If you are going to make a generic function, make it for everyone. > +{ > + const __be32 *reg; > + > + reg =3D of_get_flat_dt_prop(node, propname, NULL); > + if (!reg) > + return -EINVAL; > + > + *retval =3D be32_to_cpup(reg); > + return 0; > +} > + > +static u32 __init get_block_size_pages(u32 block_size_bytes) > +{ > + u32 a =3D PAGE_SIZE; > + u32 b =3D block_size_bytes; > + u32 r; > + > + /* Find greatest common divisor using the Euclidian algorithm. */ > + do { > + r =3D a % b; > + a =3D b; > + b =3D r; > + } while (b !=3D 0); > + > + return PHYS_PFN(PAGE_SIZE * block_size_bytes / a); > +} > + > +static int __init fdt_init_tag_storage(unsigned long node, const char *u= name, > + int depth, void *data) > +{ > + struct tag_region *region; > + unsigned long mem_node; > + struct range *mem_range; > + struct range *tag_range; > + u32 block_size_bytes; > + u32 nid =3D 0; > + int ret; > + > + if (depth !=3D 1 || !strstr(uname, "tag-storage")) > + return 0; > + > + if (!of_flat_dt_is_compatible(node, "arm,mte-tag-storage")) > + return 0; > + > + if (num_tag_regions =3D=3D MAX_TAG_REGIONS) { > + pr_err("Maximum number of tag storage regions exceeded"); > + return -EINVAL; > + } > + > + region =3D &tag_regions[num_tag_regions]; > + mem_range =3D ®ion->mem_range; > + tag_range =3D ®ion->tag_range; > + > + ret =3D tag_storage_of_flat_get_tag_range(node, tag_range); > + if (ret) { > + pr_err("Invalid tag storage node"); > + return ret; > + } > + > + ret =3D tag_storage_get_memory_node(node, &mem_node); > + if (ret) > + return ret; > + > + ret =3D tag_storage_of_flat_get_memory_range(mem_node, mem_range)= ; > + if (ret) { > + pr_err("Invalid address for associated data memory node")= ; > + return ret; > + } > + > + /* The tag region must exactly match the corresponding memory. */ > + if (range_len(tag_range) * 32 !=3D range_len(mem_range)) { > + pr_err("Tag storage region 0x%llx-0x%llx does not cover t= he memory region 0x%llx-0x%llx", > + PFN_PHYS(tag_range->start), PFN_PHYS(tag_range->en= d), > + PFN_PHYS(mem_range->start), PFN_PHYS(mem_range->en= d)); > + return -EINVAL; > + } > + > + ret =3D tag_storage_of_flat_read_u32(node, "block-size", &block_s= ize_bytes); > + if (ret || block_size_bytes =3D=3D 0) { > + pr_err("Invalid or missing 'block-size' property"); > + return -EINVAL; > + } > + region->block_size =3D get_block_size_pages(block_size_bytes); > + if (range_len(tag_range) % region->block_size !=3D 0) { > + pr_err("Tag storage region size 0x%llx is not a multiple = of block size %u", > + PFN_PHYS(range_len(tag_range)), region->block_size= ); > + return -EINVAL; > + } > + > + ret =3D tag_storage_of_flat_read_u32(mem_node, "numa-node-id", &n= id); I was going to say we already have a way to associate memory nodes other nodes using "numa-node-id", so the "memory" phandle property is somewhat redundant. Maybe the tag node should have a numa-node-id. With that, it looks like you don't even need to access the /memory node. Avoiding that would be good for 2 reasons. It avoids parsing memory nodes twice and it's not the kernel's job to validate the DT. Really, if you want memory info, you should use memblock to get it because all the special cases of memory layout are handled. For example you can have memory nodes with multiple 'reg' entries or multiple memory nodes or both, and then some of those could be contiguous. Rob