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
