Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM

[Baolu Lu]

On 2024/9/14 10:53, Tian, Kevin wrote:
> > From: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx>
> > Sent: Saturday, September 14, 2024 9:18 AM
> >
> > On 9/14/24 8:52 AM, Tian, Kevin wrote:
> > > > From: Joel Granados via B4 Relay
> > > > <devnull+j.granados.samsung.com@xxxxxxxxxx>
> > > >
> > > > From: Joel Granados<j.granados@xxxxxxxxxxx>
> > > >
> > > > IO page faults are no longer dependent on CONFIG_INTEL_IOMMU_SVM.
> > > > Move
> > > > all Page Request Queue (PRQ) functions that handle prq events to a new
> > > > file in drivers/iommu/intel/prq.c. The page_req_des struct is now
> > > > declared in drivers/iommu/intel/prq.c.
> > > >
> > > > No functional changes are intended. This is a preparation patch to
> > > > enable the use of IO page faults outside the SVM/PASID use cases.
> > > Do we want to guard it under a new config option e.g.
> > > CONFIG_INTEL_IOMMU_IOPF? it's unnecessary to allocate resources
> > > for the majority usages which don't require IOPF.
> > >
> > > Baolu?
> > The OS builder doesn't know if Linux will run on a platform with PRI-
> > capable devices. They'll probably always enable this option if we
> > provide it.
> hmm then why do we need a SVM option? In reality I haven't seen
> a platform which supports IOPF but no pasid/SVM. so the reason
> for whether to have an option should be same between IOPF/SVM.
>
> IMHO the point of options is to allow reducing footprint of the kernel
> image and many options are probably always enabled in distributions...

To be honest, I would hope to remove the SVM option some day. It's
nothing special except listening to an external notification and
synchronize the caches when the page table is updated. It's common to
all cases where a page table is shared between the IOMMU and another
component.

As for CONFIG_INTEL_IOMMU_IOPF, my suggestion is that we don't need to
add any unnecessary options unless we see a real need.

Thanks,
baolu