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;
Date:   Tue, 20 Sep 2022 13:27:27 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Jacob Pan <jacob.jun.pan@intel.com>,
        Ashok Raj <ashok.raj@intel.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Ashok Raj <ashok_raj@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
        Kostya Serebryany <kcc@google.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Alexander Potapenko <glider@google.com>,
        Taras Madan <tarasmadan@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "H . J . Lu" <hjl.tools@gmail.com>,
        Andi Kleen <ak@linux.intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCHv8 00/11] Linear Address Masking enabling
Message-ID: <Yynp77km4SaHpe/3@nvidia.com>
References: <20220914144518.46rhhyh7zmxieozs@box.shutemov.name>
 <YyHvF2K7ELVSTGvB@araj-MOBL2.amr.corp.intel.com>
 <20220914151818.uupzpyd333qnnmlt@box.shutemov.name>
 <YyHz7H0uyqG58b3E@araj-MOBL2.amr.corp.intel.com>
 <20220914154532.mmxfsr7eadgnxt3s@box.shutemov.name>
 <20220914165116.24f82d74@jacob-builder>
 <20220915090135.fpeokbokkdljv7rw@box.shutemov.name>
 <20220915172858.pl62a5w3m5binxrk@box.shutemov.name>
 <Yym8zsuXbYaW3alU@nvidia.com>
 <15741fdf-68b6-bd32-b0c2-63fde3bb0db2@intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <15741fdf-68b6-bd32-b0c2-63fde3bb0db2@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?6kJ2Bw8IQnzbM+cLfvg3NlutQlhPHoTIe1dPEUfdNQ/EK0gx8e/HHnyheUn5?=
 =?us-ascii?Q?lHolw8Ednos6ZMLp/cdyEnKZYKY732X2KOLjh1qgvyY88iKD0TVgc9OTB/W0?=
 =?us-ascii?Q?UV3+W0MfG1PYfGso3nAJVdF9ZCestFNKWqE2AY1su3oxUGR26Kfw9P1P9FpM?=
 =?us-ascii?Q?X2/p7WeIBv1RW3MTjcIHjYZQ51BRpSb/I4D3QJFdjAFTNWHrjr2Ayp/fLaBZ?=
 =?us-ascii?Q?xQuJ2QLh4TF0Bgl/ON2l7s7JNTAH01rte44t31xDMBmpzXLit7dIkzCooYNP?=
 =?us-ascii?Q?+vmLKoF3LqnSNsdLSEgp/jL2GGnh0DP2NfPW7CcPOyWCQzZn9CadFwZRiV52?=
 =?us-ascii?Q?SKJNNEdQkfqdrHNR5QazwC2FDUDFsTV297+Y9AKL+buuvhw2fZpKCzSMW7H/?=
 =?us-ascii?Q?T12wtAdve8uFXUHdKtvpNWZEqe6Q5Ab6LwXhUXuCShTaJb6YN1Ap1p5cfcfn?=
 =?us-ascii?Q?LymXghdAlAuvdJq6V4+tFzfARLHbQVqYKoOyfiKwiyiKG7RNsHhdU1axdoWc?=
 =?us-ascii?Q?fKOoaibSut+CA7K3YdGlZmdXIWS0OwOb5p3r2PN3+9u2P3qtGUa/zLe+6KF3?=
 =?us-ascii?Q?3YYNXfK2ysxdQMNF7Rw00/jvO2hSqdeJcmtEo0dXldUmappfbh2tPggc2iPz?=
 =?us-ascii?Q?0wfx1J3b5794SjvFC2rzNZU13sITJlZqTjQBN+O7P1wM+Xp9FjVLslYGCkT8?=
 =?us-ascii?Q?kCvRz3ssmzpdw2wzKKgtBoAds3BuoWSKVL3i9ksdOdmyRSDkjUM5sonXYqjn?=
 =?us-ascii?Q?8KE30R1NjHND6qGr/smu9eyGfsX/+Ba6VaY+I4FkkCEwoFfSlDbt5mOMsYHX?=
 =?us-ascii?Q?NobP191y0EShbznM8if7zEULZOO1yDmi6K6SlqUZYsicHkpj3akgdE3hQPLI?=
 =?us-ascii?Q?mCiuw1wJzcN9UoKLoTshd6UO2nRdU+a/HiojEt7tDypjDbFUBbnZYsXRdj/G?=
 =?us-ascii?Q?SMokNCoI94oWeXa5ij0saSH28irboR6I8okPOm8QAiKuKNlXEeyKQFMGLBse?=
 =?us-ascii?Q?fxk++KfGaST5TCz2TVx2CHxrlxHGTY3K6L9uZqTn9dK7aGIE54Otf+6v9dHd?=
 =?us-ascii?Q?WPjpsImprYbXfTUrgaI/i8I3zXi8yMydAc43ji4QwoHrKLUszZZaAKdBrvvW?=
 =?us-ascii?Q?OymGNuW8iJU9CninI5p3Khmk3rRjZWhpx5mBSZFko6/CcP2A0MGD3NzlbgBn?=
 =?us-ascii?Q?40HA/m7OVbHIugX2tfAjx2b30Q3+HjynDGDw4JBdAtTuGCwKVPbPejko2hx0?=
 =?us-ascii?Q?xDKxUN6+tzkCgEROTFQORLr5T2ylhh4rWQQnaGprh/5TylWFTDWX2Ut/XO6D?=
 =?us-ascii?Q?TMI+rjjabbErgOO1gcN7s44HJlEivn8c1WATF3dhPezJQqF99M8ecZlqVp2y?=
 =?us-ascii?Q?uT+qWnRC7SazRxqz6U5b2/pzeIHGBP3I83+3gZ9dGN8zqb6n773I45vFffpM?=
 =?us-ascii?Q?RKpNgPBWBgMhK+a+FqNqO2gvjWz93Mj1ubS4JG6jLUcEEKaL0pqA1ME/Rpvx?=
 =?us-ascii?Q?gvmoe778bFQVtFrTk9HSqty2EDWaTLcNi/XPTtWm2I+AM3FWJm/MOSvuF796?=
 =?us-ascii?Q?Elby/jB8xdQFT82yqlzHHzZGMAfqkYM3Y2wf8Lal?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89b97e57-ea0e-4115-2d1e-08da9b2502bc
X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4192.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2022 16:27:31.8181
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: F+788yMObFufwhi7NLhELIMPQorpfItdOYRXP4Tb9C5OVD35zb7N/BwT9YM5RX3f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6551
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no 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

On Tue, Sep 20, 2022 at 09:06:32AM -0700, Dave Hansen wrote:
> On 9/20/22 06:14, Jason Gunthorpe wrote:
> > For this I would rather have a function that queries the format of the
> > page table under the mm_struct and we have enum values like
> > INTEL_NORMAL and INTEL_LAM as possible values.
> > 
> > The iommu driver will block incompatible page table formats, and when
> > it starts up it should assert something that blocks changing the
> > format.
> 
> That doesn't sound too bad.  Except, please don't call it a "page table
> format".  The format of the page tables does not change with LAM.  It's
> entirely how the CPU interprets addresses that changes.

Sure it does. The rules for how the page table is walked change. The
actual bits stored in memory might not be different, but that doesn't
mean the format didn't change. If it didn't change we wouldn't have an
incompatibility with the IOMMU HW walker.

> Oh, and please don't call things "INTEL_WHATEVER".  It looks silly and
> confuses the heck out of people when a second CPU vendor needs to use
> the same code.

I don't mean something where a second CPU vendor would re-use the
code, I mean literally to specify the exact format of the page tables,
where each CPU and configuration can get its own code. eg "Intel
x86-64 format 5 level, no lam"

At the end of the day the iommu drivers need to know this information
so they can program the HW to walk the same tables.

Today it is all implicit that if you have an iommu driver then it can
make assumptions about the layout, but if we add an API we may as well
be a bit more explicit at the same time.

Jason