Re: [PATCHv8 00/11] Linear Address Masking enabling

[Jacob Pan]

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