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 E0E6CC282EC for ; Fri, 14 Mar 2025 17:56:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2F23280004; Fri, 14 Mar 2025 13:56:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE05D280001; Fri, 14 Mar 2025 13:56:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A916280004; Fri, 14 Mar 2025 13:56:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7C2EB280001 for ; Fri, 14 Mar 2025 13:56:19 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D2A7D1213B3 for ; Fri, 14 Mar 2025 17:56:19 +0000 (UTC) X-FDA: 83220910878.04.BF28B17 Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) by imf02.hostedemail.com (Postfix) with ESMTP id 5D3A580009 for ; Fri, 14 Mar 2025 17:56:16 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=d+uoEhMG; spf=pass (imf02.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741974978; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0BQq+xAUXw60P/WE4bsmNx/WDxIn+sXXBd4O7Hava98=; b=64pu7ttTKNykisahKaBbEPFh8/F1EjB8GbWn1siislDKTpKon0qJAOVifI0t7VtAeDL4EZ ilF5MlkPAoZ6EaVvt5VM7yQLTk4i7I6IcS6rdyvQcJ4DR0BB+sIP85afD0KibarATyOXzl RRJvUaK0lwNps/V3rIID1bkAGijhmWo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741974978; a=rsa-sha256; cv=none; b=xe65KTcBP4fukBZ2M1pGb2KNqQ7BNAHjcwyIjxNVPun9kZrDHv6X/7geE4/vR8F2eXQms9 eXa9ej1nncAJ/G7KBdxvswte6QAY9xBBzkne990avJtfzrVfqSapkjyhAboAuSPTZmbmHO QJLPch8dRDU3uI0CUWZ376GYcdBqZHU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=d+uoEhMG; spf=pass (imf02.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Fri, 14 Mar 2025 17:56:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1741974972; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0BQq+xAUXw60P/WE4bsmNx/WDxIn+sXXBd4O7Hava98=; b=d+uoEhMG5JP4+cAPvMVU5tsk/NNKrtJjzzDxQt0oICJuSR6SVt3GPfUnoBT/gvSLdRfwCj bVa/b43CObA8GFyMyeLk8DWajc20Z3qYilR3LkAtRzB6x4gQZZKv4rhlBGyYFW5YVD1z4n 3btLDqoJP/58bzLTXF4kPuiXJk47JXE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Brendan Jackman Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Andrew Morton , David Rientjes , Vlastimil Babka , David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Rapoport , Junaid Shahid , Reiji Watanabe , Patrick Bellasi Subject: Re: [PATCH RFC 03/11] x86/mm: Add lookup_pgtable_in_pgd() Message-ID: References: <20250313-asi-page-alloc-v1-0-04972e046cea@google.com> <20250313-asi-page-alloc-v1-3-04972e046cea@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5D3A580009 X-Stat-Signature: bj8bi1pjh7zudfj7es4huk8339ucczy8 X-HE-Tag: 1741974976-472209 X-HE-Meta: U2FsdGVkX19ApyEVe4j97ciCiFoI0s+tvP4xfH0nnuqbm4pUzyRwpkrSaOaHX0NnbeB5wEdrrZNf+BzwRDE4MYpubSsFhzT+vJXT8HltKrR2j0659Fcq1YMoWezqI+hvAYO8uHcM/e3eXIjIW6lpdzlRSmL/teX2h5rT7aj7iKyRotFJNv5XefxYaW1tpAOcU21x5sfV6NK71hGXMMhdsBa4ZAb/1MOlOlCArYmwNVBgCkpR2Qs1DmPkUOOUPdwAuyJzhMCnneN/VCYeJETCbN9piKwYTb2XZs9Xav2KIVNYwxICp1klWUi6UhjaWClAfT7KPNFyLzbSd6cC1fwTmQMzIvOPDDkrkrbYP7GPivvGpcfWsVoDDPPOr4WUK0VhC7rdGLQY3m6gAWQq1lXsYtwruhQKYRHIOdxoxx6NcBqyOexPJ4DCp5kD+OashSDH+MHtlzwodOk9i5l5gdcKI/Gpa+pC6UPo5iMyTBnkkejn8roTjgU8+nvm8Ts4iFjtcoSEQjoN275XyKU4vjSnTLjqXJM07VAshAS2iG1EBhmbQ/9eN2+OseYTsnuMysDSWLX6J0cOMYiAxbxNHwJJl8B63S+9QLGvznAb5gbpISEet4wRwcdu6U0gxCSrObtMQ/9Gfp5mpmG+URZaj6tA6e9bBq7KR6h2Hx+/g0oL4J/W7IqosZ292EPw6gJQEfAJZiPTXfZZiNGJYSR7h4gc0VSEXVAz8qB/hZE0X4ytYM85B9s9d1Ye6JQOeW3ARVM5VcCtaJjF7FRPDmAu42SXf7nC+cyQeBTTZx633kTfzT84OHvxPD+gDHM/j8lBEKgUMMA7IoIPiqluenkaPT5i858ca7rLxCBvUN1BgwZBAW3225NBm/uaEcEjuQ2Q/Fro9Y+6+GPhdape6V8Xo2dMEC0ByqEfqGC5+mQW2oJekOmXyV0WEuzAawidgDPEMDoESeNIeO682TKnIVt7+kA hqFdrTt8 3pI1TB3NGMQmuRXNP16XB6AQn4/lufdlpGywAkQdPJz3zfIUBkPaT1e0RSfRJjdER3x9pu5CrWx5paEna4+Eyv35Qy7TF4oBBPoRZfjSwYxnlc4cBtZbYh2jF1sweDyeBrIln2TbY2fzLpZTXCIZNlKOw6MG5X0Wr6DlPOR+BiCSwetUTGwP4ukgNAu+y2LX7NDJyLbt88eeqKWzTXAW4pLKiKiL5YceH/J95xBB9AKYXB0EgkOpuB9bl7Kpd+PA3/2mBAAdm4oge21DjXej1+O9ohTbu++hygkeyYFE4KVTDl/c= 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 Fri, Mar 14, 2025 at 09:12:04AM +0000, Brendan Jackman wrote: > On Thu, Mar 13, 2025 at 10:09:21PM +0000, Yosry Ahmed wrote: > > On Thu, Mar 13, 2025 at 06:11:22PM +0000, Brendan Jackman wrote: > > > This is the same thing as lookup_address_in_pgd(), but it returns the > > > pagetable unconditionally instead of returning NULL when the pagetable > > > is none. This will be used for looking up and modifying pages that are > > > *_none() in order to map memory into the ASI restricted address space. > > > > > > For a [PATCH], if this logic is needed, the surrounding code should > > > probably first be somewhat refactored. It now looks pretty repetitive, > > > and it's confusing that lookup_address_in_pgd() returns NULL when > > > pmd_none() but note when pte_none(). For now here's something that > > > works. > > > > My first instinct reading this is that lookup_address_in_pgd() should be > > calling lookup_pgtable_in_pgd(), but I didn't look too closely. > > Yeah. That outer function would get a "generic" PTE pointer isntead of > a strongly-typed p4d_t/pud_t/etc. So we either need to encode > assumptions that all the page tables have the same structure at > different levels for the bits we care about, or we need to have a > switch(*level) and then be careful about pgtable_l5_enabled(). I > think the former is fine but it needs a bit of care and attention to > ensure we don't miss anything and avoid creating > confusion/antipatterns in the code. Hmm another option is to have a common helper that takes in a lot of parameters to control the exact behavior (e.g. do we check for 'none'?), and have both lookup_pgtable_in_pgd() and lookup_address_in_pgd() call it with different parameters. This could avoid the need for a generic pointer, for example. > > And perhaps more importantly, lookup_adress_in_pgd_attr() sets *nx and > *rw based on the level above the entry it returns. E.g. when it > returns a pte_t* it sets *nx pased on pmd_flags(). I haven't looked > into why this is. > > So yeah overall it needs a bit of research and most likely needs a > couple of prep patches. Hopefully it's possible to do it in a way that > leaves the existing code in a clearer state. Agreed. > > Anyway, I was originally planning not to have asi_map()/asi_unmap() in > asi.c at all, and instead just kinda make set_memory.c natively aware > of ASI somehow. At that point I think this code is probably gonna look > a bit different. That's something I ran out of time for and had to > drop from the scope of this RFC. It's definitely not ideal in this > series that e.g. page_alloc.c, asi.c, and set_memory.c are all > implicitly coupled to one another (i.e. they are all colluding to > ensure asi_[un]map() never has to allocate). Maybe I should've called > this out as a TODO on the cover letter actually. Looking forward to seeing how this would look like :)