Hi Jason, On Tue, 20 Sep 2022 13:27:27 -0300, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > 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. There are many CPU-IOMMU compatibility checks before we do for SVA,e.g. we check paging mode in sva_bind. We are delegating these checks in arch/platform code. So why can't we let arch code decide how to convey mm-IOMMU SVA compatibility? let it be a flag ( as in this patch) or some callback. Perhaps a more descriptive name s/arch_can_alloc_pasid(mm)/arch_can_support_sva(mm)/ is all we disagreeing :) Thanks, Jacob
