On Wed, Mar 24, 2021 at 03:12:30PM -0700, Jacob Pan wrote:

Hi Jason,

On Wed, 24 Mar 2021 14:03:38 -0300, Jason Gunthorpe [off-list ref] wrote:

quoted

On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote:

quoted

quoted

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?  

There is not much in the kernel that isn't triggered by a process, I
would be careful about the idea that there is a class of users that
can consume a cgroup controlled resource without being inside the
cgroup.

We've got into trouble before overlooking this and with something
greenfield like PASID it would be best built in to the API to prevent
a mistake. eg accepting a cgroup or process input to the allocator.

Make sense. But I think we only allow charging the current cgroup, how about
I add the following to ioasid_alloc():

	misc_cg = get_current_misc_cg();
	ret = misc_cg_try_charge(MISC_CG_RES_IOASID, misc_cg, 1);
	if (ret) {
		put_misc_cg(misc_cg);
		return ret;
	}

Does that allow PASID allocation during driver probe, in kernel_init or
modprobe context?

Thanks,
Jean