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 3A59EC4332F for ; Wed, 13 Dec 2023 17:22:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B53BB6B0368; Wed, 13 Dec 2023 12:22:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B04646B036B; Wed, 13 Dec 2023 12:22:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CBF56B036D; Wed, 13 Dec 2023 12:22:39 -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 8DA626B0368 for ; Wed, 13 Dec 2023 12:22:39 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 506651C0FA2 for ; Wed, 13 Dec 2023 17:22:39 +0000 (UTC) X-FDA: 81562464438.07.AA07EED Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf17.hostedemail.com (Postfix) with ESMTP id C91F840026 for ; Wed, 13 Dec 2023 17:22:36 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nCjqTyEE; spf=pass (imf17.hostedemail.com: domain of robh@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=robh@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702488157; 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=FXtWXQ8p5HFCgSrHs2J9VhXyyDsV0r5Wq/OxD2AU16s=; b=kxDDeH4xfEqO6K+eHAMNMeMD08FfxHpUp6xbLPvK9GGqVF2FEeHhJFLfFnzu+5RYlRxfr7 aXCOkHFV+cixRv7lXjFgle/vScyrl5SlgDUz/MSGzKLwuuNHyEZJq+g0c/B3HtUd6qoicD 0c//dHeDC7xnN+pYBuDWU4wytU1g/R4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702488157; a=rsa-sha256; cv=none; b=qV9HvCVJcwiKhKfNzEgWSM0MUd2qTx3Icy+VGKSymOnC13NlVFxzj/nvTG+PyZ6kWhmP3W 4VUbOf8m5KNMggi15sUaYu9Uw7NynUmrlSM4+3nz59VnTNEVadhv2urWY2oDsMU1xdH30Y hMeFYryMsop1Wk7+/P1CCoKANPq7Yqw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=nCjqTyEE; spf=pass (imf17.hostedemail.com: domain of robh@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=robh@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 2EB64CE207A for ; Wed, 13 Dec 2023 17:22:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EE41C433CC for ; Wed, 13 Dec 2023 17:22:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702488152; bh=MdFfxmRqnU2pgiKIHVjpuT5qM/n8AmSOleAkAeYhZzY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=nCjqTyEEwYAqdW8/rlU/X2qNfvBr2d9kOIKAiAWZ9qncIg+m+22IilZcJEY8VRoTX 7PgbJV6HZ5JLE3sDdfsX2UHiaQmp3mY3zRbfmkxhAQWJ83UeIlzK3XIiaKF4vV3C3f l9pxj+2hx8VjnlJ2uwTuDTSGTfuTbmQMk1sflXBlXe0SOkan+3n93ddJV7VKUEfu0Z MZFFlYrGAojnFk9Ri12mVxePt5n8d5wu+mgtpl3OjT9ECbV+/ED8mE03YSGnU9dACx ItkqIXFCrBxK8l26h8/TEEuSPhBnj4lDFVScIjFLiDXKOzURPiqtz1dSaT/lmYKVu+ rig24IG2XtNVw== Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-50bf37fd2bbso9710811e87.0 for ; Wed, 13 Dec 2023 09:22:32 -0800 (PST) X-Gm-Message-State: AOJu0YyB8BAJt88wy5rtNeDXUspWQVs+sOhpxw4dDrL1ESZ2QpeMatkN tgTWKS+WJcWW8CvT+lXFSymZXwxqyyQBf14new== X-Google-Smtp-Source: AGHT+IFqzlN5cXgUWTtVKqvQkSS2vQPSTV20xZkO0pzlfuqEtQX8svaifgRBAAqLPVw/kWvXPFUvtTzHkFE1kxDLXyI= X-Received: by 2002:ac2:5504:0:b0:50c:a39:ee37 with SMTP id j4-20020ac25504000000b0050c0a39ee37mr4154700lfk.109.1702488150631; Wed, 13 Dec 2023 09:22:30 -0800 (PST) MIME-Version: 1.0 References: <20231119165721.9849-1-alexandru.elisei@arm.com> <20231119165721.9849-12-alexandru.elisei@arm.com> In-Reply-To: From: Rob Herring Date: Wed, 13 Dec 2023 11:22:17 -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: C91F840026 X-Rspam-User: X-Stat-Signature: 7sci5k5pkwmd56q4y3gy6ah1xbigm3p1 X-Rspamd-Server: rspam03 X-HE-Tag: 1702488156-106331 X-HE-Meta: U2FsdGVkX1+YYL8XUhrBqZ8QO94VmYIr5ELKNOmcuvqP0oieNYRQcJ+o9PlwHLLdMYuHilyNwKNnv5xR5dYZ3SGOYpCJZhfE/uQ01n9Tu1HJYoC+tU3ViZ9x9tFXCqkYYT4qfZCtHv5E/TTaGErodUwxREDkzUjkxFXlAxak7rksJQLlvPnTdzo80Ti/LCIr0EycXQ/nl2oTQssG75KNlF8SJJZ4a4+2L8nAvKnqlf9zHZWTDhHxD4mRUyEKHse9cP7mKCrGJ8ra8GFFDb6NXNeQubBHfX2O6fWYiMb5r/JdMGnaaDW+uLFnS8HqLP9bdx24tNPTL4oB71Q4POruPp4KbnuMtpk3zD1n7Pb2F3Y4TzlbcKa18dlOY4CgaxzsMkA6Y496r0XgdEaszXp1FQqY4iF1vdiLdvCCw9VGbvruO+1nGkU7ttOnio0BVIcqX9/BPwxw0RniVWnT/FnWPQ0LKy5r+AfDn91aMbSuMyRfVcnyfNuA3GeaDOngHSSL/iZpyrXQwey/aIgROKSm4f7/8LrnES7cxpIUKOkJBeOa25kL5tOLjTPQiRRPSL/ThTg0sA+LBZxseJ1miunx5VYMnsqv1EOx0gM6GAVrIOvYYVoiiC/+cBPzHbNtdk4WI2licZph+pri8N2bleFCb74iu00gFOnuevtVaIr8yxwbThTV4D8zDJLLC/MGd1tb6EjI7UR9Z+Cf+eI5Tmx0jXUV2yPefQNI6B7/Dmd3ccO3fLv3eLnzTkw9T+dtsdhjYBqylZ3uob2Havs/3yIpdu5aYXO/qh/dXLQHIHJLezxMQwTC1cBzVgtxD196OxXhexini93ynIuz4N4gk7TTQaQpqsRnwC2EyIRetbRl85z9hrbFRlx2iooP1Eh/3H5qo3/IhV10KUwxeaNeQ5awfqSOu5UaJP4RJaA/c/3f+h1HGasj/7ZObYUwA8MBAVHttEgZpCZKBrQi+yEZe7H xxYkUeCU 4ijPBdlQ2NOWhAjMHUAAOGobbHffonZnMX5L5TpAjz4elU1zZ69OFdsGaq5GDQJ/I2BaKdfRbH/kQpWPEiBqbzaIPoN4vRzWtiEHWWlqpXpOHseeX1yYqdElEe+JuzY+eyR8D0dLxVt5qcET2bARQxnagtzHfyYaXupt19oWEwZCIiUCcLdsvhdf8OQr8uBN339f6FMPAahG3vnCqpoWYX577oXZOlFGyaH2SYq4NKtATJfMCHZRXpYZHsyTfvj6B/ky9VMdCePmCQ3X1OwRELZ85nWHjO1irH8NsQsiUldUR+F+yJuYMPQRlkQ== 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 Wed, Dec 13, 2023 at 8:51=E2=80=AFAM Alexandru Elisei wrote: > > Hi, > > On Wed, Dec 13, 2023 at 08:06:44AM -0600, Rob Herring wrote: > > On Wed, Dec 13, 2023 at 7:05=E2=80=AFAM Alexandru Elisei > > wrote: > > > > > > Hi Rob, > > > > > > On Tue, Dec 12, 2023 at 12:44:06PM -0600, Rob Herring wrote: > > > > On Tue, Dec 12, 2023 at 10:38=E2=80=AFAM Alexandru Elisei > > > > wrote: > > > > > > > > > > Hi Rob, > > > > > > > > > > Thank you so much for the feedback, I'm not very familiar with de= vice tree, > > > > > and any comments are very useful. > > > > > > > > > > On Mon, Dec 11, 2023 at 11:29:40AM -0600, Rob Herring wrote: > > > > > > 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 n= ow. > > > > > > > > > > > > > > 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 tagge= d memory node > > > > > > > }; > > > > > > > > > > > > I skimmed thru the discussion some. If this memory range is wit= hin > > > > > > main RAM, then it definitely belongs in /reserved-memory. > > > > > > > > > > Ok, will do that. > > > > > > > > > > If you don't mind, why do you say that it definitely belongs in > > > > > reserved-memory? I'm not trying to argue otherwise, I'm curious a= bout the > > > > > motivation. > > > > > > > > Simply so that /memory nodes describe all possible memory and > > > > /reserved-memory is just adding restrictions. It's also because > > > > /reserved-memory is what gets handled early, and we don't need > > > > multiple things to handle early. > > > > > > > > > Tag storage is not DMA and can live anywhere in memory. > > > > > > > > Then why put it in DT at all? The only reason CMA is there is to se= t > > > > the size. It's not even clear to me we need CMA in DT either. The > > > > reasoning long ago was the kernel didn't do a good job of moving an= d > > > > reclaiming contiguous space, but that's supposed to be better now (= and > > > > most h/w figured out they need IOMMUs). > > > > > > > > But for tag storage you know the size as it is a function of the > > > > memory size, right? After all, you are validating the size is corre= ct. > > > > I guess there is still the aspect of whether you want enable MTE or > > > > not which could be done in a variety of ways. > > > > > > Oh, sorry, my bad, I should have been clearer about this. I don't wan= t to > > > put it in the DT as a "linux,cma" node. But I want it to be managed b= y CMA. > > > > Yes, I understand, but my point remains. Why do you need this in DT? > > If the location doesn't matter and you can calculate the size from the > > memory size, what else is there to add to the DT? > > I am afraid there has been a misunderstanding. What do you mean by > "location doesn't matter"? You said: > Tag storage is not DMA and can live anywhere in memory. Which I took as the kernel can figure out where to put it. But maybe you meant the h/w platform can hard code it to be anywhere in memory? If so, then yes, DT is needed. > At the very least, Linux needs to know the address and size of a memory > region to use it. The series is about using the tag storage memory for > data. Tag storage cannot be described as a regular memory node because it > cannot be tagged (and normal memory can). If the tag storage lives in the middle of memory, then it would be described in the memory node, but removed by being in reserved-memory node. > Then there's the matter of the tag storage block size (explained in this > commit message), and also knowing the memory range for which a tag storag= e > region stores the tags. This is explained in the cover letter. Honestly, I just forgot about that part. Rob