From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [RFC PATCH 15/18] cgroup: Introduce ioasids controller Date: Wed, 3 Mar 2021 20:23:57 -0400 Message-ID: <20210304002357.GY4247@nvidia.com> References: <1614463286-97618-1-git-send-email-jacob.jun.pan@linux.intel.com> <1614463286-97618-16-git-send-email-jacob.jun.pan@linux.intel.com> <20210303131726.7a8cb169@jacob-builder> <20210303160205.151d114e@jacob-builder> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20210303160205.151d114e@jacob-builder> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1614817444; bh=aIwvvpE4wGoBAdK1+JiL6a3DRIITWKYkTYWOnUwBXbw=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:Date: From:To:CC:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:X-ClientProxiedBy:MIME-Version: X-MS-Exchange-MessageSentRepresentingType:X-Header; b=C3fjXaTiJBKO1GYRDJrCCxB7V2sCABjNAU8GwkVL7OgiP2eaQQhwz77qemjqv2HWG Ur0ALQQj7VoRWcK74JUXIAo6+w0CUQ2u7PuU9l8jvnXVeaxsaHVpuaPCrjjM4R1043 QNxly8dOmrEdVq7/0RAaTXgjlA1cBCIqoiugq07vYKnuQ8YkPJZQtVFihRibWUvyQX sG7mW0uDkK3pgJouCW4jfadroRjQvwWwZr5oe10GAXxw63aopaVF0YCsKuumeLEyx3 UmYjK/zIitVVODJ0TossHZvjZq3g3/chw/RpLRUQnVTSwaV6tqQdk5D1PTwhz6ezUN QRd1sctf32nvg== 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, Johannes Weiner , Tejun Heo , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Wu Hao , David Woodhouse On Wed, Mar 03, 2021 at 04:02:05PM -0800, Jacob Pan wrote: > > The interface definitely can be reused. But IOASID has a different > > behavior in terms of migration and ownership checking. I guess SEV key > > IDs are not tied to a process whereas IOASIDs are. Perhaps this can be > > solved by adding > > + .can_attach = ioasids_can_attach, > > + .cancel_attach = ioasids_cancel_attach, > > Let me give it a try and come back. > > > While I am trying to fit the IOASIDs cgroup in to the misc cgroup proposal. > I'd like to have a direction check on whether this idea of using cgroup for > IOASID/PASID resource management is viable. > > Alex/Jason/Jean and everyone, your feedback is much appreciated. IMHO I can't think of anything else to enforce some limit on a HW scarce resource that unpriv userspace can consume. Jason