Hi Jean-Philippe,

On Mon, 22 Mar 2021 10:24:00 +0100, Jean-Philippe Brucker
[off-list ref] wrote:

On Fri, Mar 19, 2021 at 11:22:21AM -0700, Jacob Pan wrote:

quoted

Hi Jason,

On Fri, 19 Mar 2021 10:54:32 -0300, Jason Gunthorpe [off-list ref]
wrote: 

quoted

On Fri, Mar 19, 2021 at 02:41:32PM +0100, Jean-Philippe Brucker
wrote:  

quoted

On Fri, Mar 19, 2021 at 09:46:45AM -0300, Jason Gunthorpe wrote:    

quoted

On Fri, Mar 19, 2021 at 10:58:41AM +0100, Jean-Philippe Brucker
wrote: 

quoted

Although there is no use for it at the moment (only two upstream
users and it looks like amdkfd always uses current too), I quite
like the client-server model where the privileged process does
bind() and programs the hardware queue on behalf of the client
process.    

This creates a lot complexity, how do does process A get a secure
reference to B? How does it access the memory in B to setup the
HW?    

mm_access() for example, and passing addresses via IPC    

I'd rather the source process establish its own PASID and then pass
the rights to use it to some other process via FD passing than try to
go the other way. There are lots of security questions with something
like mm_access.
  

Thank you all for the input, it sounds like we are OK to remove mm
argument from iommu_sva_bind_device() and iommu_sva_alloc_pasid() for
now?  

Fine by me. By the way the IDXD currently missues the bind API for
supervisor PASID, and the drvdata parameter isn't otherwise used. This
would be a good occasion to clean both. The new bind prototype could be:

struct iommu_sva *iommu_sva_bind_device(struct device *dev, int flags)

yes, we really just hijacked drvdata as flags, it would be cleaner to use
flags explicitly.

And a flag IOMMU_SVA_BIND_SUPERVISOR (not that I plan to implement it in
the SMMU, but I think we need to clean the current usage)

You mean move #define SVM_FLAG_SUPERVISOR_MODE out of Intel code to be a
generic flag in iommu-sva-lib.h called IOMMU_SVA_BIND_SUPERVISOR?

I agree if that is the proposal.

quoted

Let me try to summarize PASID allocation as below:

Interfaces	| Usage	|  Limit	| bind¹ |User visible
--------------------------------------------------------------------
/dev/ioasid²	| G-SVA/IOVA	|  cgroup	| No
|Yes
--------------------------------------------------------------------
char dev³	| SVA		|  cgroup	| Yes	|No
--------------------------------------------------------------------
iommu driver	| default PASID|  no		| No	|No
 

Is this PASID #0?

True for native case but not limited to PASID#0 for guest case. E.g. for
mdev assignment with guest IOVA, the guest PASID would #0, but the host aux
domain default PASID can be non-zero. Here I meant to include both cases.

quoted

--------------------------------------------------------------------
kernel		| super SVA	| no		| yes   |No
--------------------------------------------------------------------  

Also wondering about device driver allocating auxiliary domains for their
private use, to do iommu_map/unmap on private PASIDs (a clean replacement
to super SVA, for example). Would that go through the same path as
/dev/ioasid and use the cgroup of current task?

For the in-kernel private use, I don't think we should restrict based on
cgroup, since there is no affinity to user processes. I also think the
PASID allocation should just use kernel API instead of /dev/ioasid. Why
would user space need to know the actual PASID # for device private domains?
Maybe I missed your idea?

Thanks,
Jean

quoted

¹ Allocated during SVA bind
² PASIDs allocated via /dev/ioasid are not bound to any mm. But its
  ownership is assigned to the process that does the allocation.
³ Include uacce, other private device driver char dev such as idxd

Currently, the proposed /dev/ioasid interface does not map individual
PASID with an FD. The FD is at the ioasid_set granularity and bond to
the current mm. We could extend the IOCTLs to cover individual PASID-FD
passing case when use cases arise. Would this work?

Thanks,

Jacob  

Thanks,

Jacob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu