> From: Joel Granados via B4 Relay
> <devnull+j.granados.samsung.com@kernel.org>
> 
> This series makes use of iommufd_hwpt_replace_device to execute
> non-pasid/non-svm user space IOPFs. Our main motivation is to enable
> user-space driver driven device verification without SVM/PASID.

can you elaborate why IOPFs are necessary to help verify such usage?

> 
> What?
>   * Enable IO page fault handling in user space for a non-pasid, non-svm
>     and non-virtualised use case.
>   * Move IOMMU_IOPF configuration from INTEL_IOMMU_SVM into
> INTEL_IOMMU.
>   * Move all page request queue related logic to a new (prq.c) file.
>   * Remove PASID checks from PRQ event handling as well as PRQ
>     initialization.
>   * Allow execution of IOMMU_HWPT_ALLOC with a valid fault id
>     (IOMMU_HWPT_FAULT_ID_VALID)
>   * Insert a zero handle into the PASID array in dev->iommu_group when
>     replacing the old HWPT with an IOPF enabled HWPT.

the last bullet is stale now.

btw a selftest is expected too.

On Sat, Sep 14, 2024 at 12:48:31AM +0000, Tian, Kevin wrote:
> > From: Joel Granados via B4 Relay
> > <devnull+j.granados.samsung.com@kernel.org>
> > 
> > This series makes use of iommufd_hwpt_replace_device to execute
> > non-pasid/non-svm user space IOPFs. Our main motivation is to enable
> > user-space driver driven device verification without SVM/PASID.
> 
> can you elaborate why IOPFs are necessary to help verify such usage?

In retrospect "enable" might not be the best word to use here. We are not
"enabling" user-space driver driven device verification as it is already
enabled; you could already poke a device from user space. But the whole poke
space was not available, you could not test IOPF without having an SVM/PASID
capable IOMMU. Therefore a better wording would be "Our main motivation is to
expand or facilitate user-space driver driven device verification by enabling
IOPF without SMV/PASID".

Does this address your concern?

> 
> > 
> > What?
> >   * Enable IO page fault handling in user space for a non-pasid, non-svm
> >     and non-virtualised use case.
> >   * Move IOMMU_IOPF configuration from INTEL_IOMMU_SVM into
> > INTEL_IOMMU.
> >   * Move all page request queue related logic to a new (prq.c) file.
> >   * Remove PASID checks from PRQ event handling as well as PRQ
> >     initialization.
> >   * Allow execution of IOMMU_HWPT_ALLOC with a valid fault id
> >     (IOMMU_HWPT_FAULT_ID_VALID)
> >   * Insert a zero handle into the PASID array in dev->iommu_group when
> >     replacing the old HWPT with an IOPF enabled HWPT.
> 
> the last bullet is stale now.
oops. Missed that one; will correct in next version 

> 
> btw a selftest is expected too.
I'll figure this out for the next version.

Thx for the review

Best
-- 

Joel Granados

> From: Joel Granados <j.granados@samsung.com>
> Sent: Monday, September 16, 2024 4:51 PM
> 
> On Sat, Sep 14, 2024 at 12:48:31AM +0000, Tian, Kevin wrote:
> > > From: Joel Granados via B4 Relay
> > > <devnull+j.granados.samsung.com@kernel.org>
> > >
> > > This series makes use of iommufd_hwpt_replace_device to execute
> > > non-pasid/non-svm user space IOPFs. Our main motivation is to enable
> > > user-space driver driven device verification without SVM/PASID.
> >
> > can you elaborate why IOPFs are necessary to help verify such usage?
> 
> In retrospect "enable" might not be the best word to use here. We are not
> "enabling" user-space driver driven device verification as it is already
> enabled; you could already poke a device from user space. But the whole
> poke
> space was not available, you could not test IOPF without having an
> SVM/PASID
> capable IOMMU. Therefore a better wording would be "Our main motivation
> is to
> expand or facilitate user-space driver driven device verification by enabling
> IOPF without SMV/PASID".
> 

hmm did you actually see a IOMMU which supports IOPF only but
not SVM/PASID? 

this series alone has its merit, e.g. postcopy migration might want
such notification. But not sure it helps solve a real problem in your side...

On Fri, Sep 20, 2024 at 06:57:04AM +0000, Tian, Kevin wrote:
> > From: Joel Granados <j.granados@samsung.com>
> > Sent: Monday, September 16, 2024 4:51 PM
> > 
> > On Sat, Sep 14, 2024 at 12:48:31AM +0000, Tian, Kevin wrote:
> > > > From: Joel Granados via B4 Relay
> > > > <devnull+j.granados.samsung.com@kernel.org>
> > > >
> > > > This series makes use of iommufd_hwpt_replace_device to execute
> > > > non-pasid/non-svm user space IOPFs. Our main motivation is to enable
> > > > user-space driver driven device verification without SVM/PASID.
> > >
> > > can you elaborate why IOPFs are necessary to help verify such usage?
> > 
> > In retrospect "enable" might not be the best word to use here. We are not
> > "enabling" user-space driver driven device verification as it is already
> > enabled; you could already poke a device from user space. But the whole
> > poke
> > space was not available, you could not test IOPF without having an
> > SVM/PASID
> > capable IOMMU. Therefore a better wording would be "Our main motivation
> > is to
> > expand or facilitate user-space driver driven device verification by enabling
> > IOPF without SMV/PASID".
> > 
> 
> hmm did you actually see a IOMMU which supports IOPF only but
> not SVM/PASID? 
> 
> this series alone has its merit, e.g. postcopy migration might want
> such notification. But not sure it helps solve a real problem in your side...

I understand that you want more information about what problem(s) are
solved by this patch set from my point of view. right?

One of the main motivations is to enable IOPF in use cases where PASID
is *not* an option, like NVMe devices. Therefore one of the examples for
enabling user-space driver driver device verification are NVMe without
PASID.

Quick Note: I am adding my new email to the thread so I get the
responses routed to the correct inbox.


-- 

Joel Granados