From: David Gibson <redacted>
Sent: Tuesday, August 10, 2021 12:48 PM

On Mon, Aug 09, 2021 at 08:34:06AM +0000, Tian, Kevin wrote:

quoted

quoted

From: David Gibson <redacted>
Sent: Friday, August 6, 2021 12:45 PM

quoted

quoted

quoted

In concept I feel the purpose of DMA endpoint is equivalent to the

routing

quoted

quoted

quoted

info in this proposal.

Maybe?  I'm afraid I never quite managed to understand the role of

the

quoted

quoted

quoted

quoted

routing info in your proposal.

the IOMMU routes incoming DMA packets to a specific I/O page table,
according to RID or RID+PASID carried in the packet. RID or RID+PASID
is the routing information (represented by device cookie +PASID in
proposed uAPI) and what the iommu driver really cares when activating
the I/O page table in the iommu.

Ok, so yes, endpoint is roughly equivalent to that.  But my point is
that the IOMMU layer really only cares about that (device+routing)
combination, not other aspects of what the device is.  So that's the
concept we should give a name and put front and center in the API.

This is how this proposal works, centered around the routing info. the
uAPI doesn't care what the device is. It just requires the user to specify
the user view of routing info (device fd + optional pasid) to tag an IOAS.

Which works as long as (just device fd) and (device fd + PASID) covers
all the options.  If we have new possibilities we need new interfaces.
And, that can't even handle the case of one endpoint for multiple
devices (e.g. ACS-incapable bridge).

why not? We have went through a long debate in v1 to reach conclusion
that a device-centric uAPI can cover above group scenario (see section 1.3)

quoted

the user view is then converted to the kernel view of routing (rid or
rid+pasid) by vfio driver and then passed to iommu fd in the attaching
operation. and GET_INFO interface is provided for the user to check
whether a device supports multiple IOASes and whether pasid space is
delegated to the user. We just need a better name if pasid is considered
too pci specific...

But creating an endpoint per ioasid and making it centered in uAPI is not
what the IOMMU layer cares about.

It's not an endpoint per ioasid.  You can have multiple endpoints per
ioasid, just not the other way around.  As it is multiple IOASes per

you need create one endpoint per device fd to attach to gpa_ioasid.

then one endpoint per device fd to attach to pasidtbl_ioasid on arm/amd.

then one endpoint per pasid to attach to gva_ioasid on intel.

In the end you just create one endpoint per each attached ioasid given 
a device.

device means *some* sort of disambiguation (generally by PASID) which
is hard to describe generall.  Having endpoints as a first-class
concept makes that simpler.

I don't think pasid causes any disambiguation (except the name itself
being pci specific). with multiple IOASes you always need an id to tag it. 
This id is what iommu layer cares about. which endpoint on the device 
uses the id is not a business to iommu.

Thanks
Kevin