From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Philippe Brucker Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs Date: Thu, 25 Mar 2021 11:21:40 +0100 Message-ID: References: <20210318172234.3e8c34f7@jacob-builder> <20210319124645.GP2356281@nvidia.com> <20210319135432.GT2356281@nvidia.com> <20210319112221.5123b984@jacob-builder> <20210324100246.4e6b8aa1@jacob-builder> <20210324170338.GM2356281@nvidia.com> <20210324151230.466fd47a@jacob-builder> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2bl+T//9tmIfvggnKu8W5/72RtiA3Lc/gNcBZ4TaNT0=; b=HDBMmQHjxhDfBDa8NUpbssXQOf02VdhzwNOvL6z/sjlS/ob6nTDjDFdk7Rx19nR1hs SQS1m7CNqJDQUJQrPvFOlRsKplOR4HvnzIgwuwJzay62ap35JEwN/qhpACoPzMAWxfWI XO4MYnlDxfTay5ZNPPLBaE8XvkwnoB0y15l1GoemjCgivvxfYqd4SqDye10bL/U1sDgq 2q58EeYToO3fsZktwBu5V51IOdt2ibMB1IaBNKKSb4cr+C+as3JCUfzbgdL92Xba3w9V ql45gXFLeCm10iNBjvSTa/BEbpZQtQ6N4qHGai0lWRLpSVaztsL2TRhlDZbX05OJR9Pk EKxw== Content-Disposition: inline In-Reply-To: <20210324151230.466fd47a@jacob-builder> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Sender: "iommu" To: Jacob Pan Cc: "Tian, Kevin" , Alex Williamson , Raj Ashok , Jonathan Corbet , Jean-Philippe Brucker , LKML , Dave Jiang , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Li Zefan , Jason Gunthorpe , Johannes Weiner , Tejun Heo , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Wu Hao , David Woodhouse 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 wrote: > > > On Wed, Mar 24, 2021 at 10:02:46AM -0700, Jacob Pan wrote: > > > > 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