From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 803AAC433E2 for ; Thu, 25 Mar 2021 17:00:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A2F061A2E for ; Thu, 25 Mar 2021 17:00:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229873AbhCYRAV (ORCPT ); Thu, 25 Mar 2021 13:00:21 -0400 Received: from mga03.intel.com ([134.134.136.65]:23725 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229592AbhCYRAL (ORCPT ); Thu, 25 Mar 2021 13:00:11 -0400 IronPort-SDR: gOpI+QLqAtR9ATCRM1zGrl+B7MOyyJfR6qX1MJJhciRrcQ50Xl51KbmJhz8/Yt7Bq2Rq1sTPmx LlGxWjsGH68g== X-IronPort-AV: E=McAfee;i="6000,8403,9934"; a="191006158" X-IronPort-AV: E=Sophos;i="5.81,278,1610438400"; d="scan'208";a="191006158" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 10:00:09 -0700 IronPort-SDR: 2y+6feWtrUcXYxfBHPesWqNmZ6kIWcDDsLyjiaRoSEn254L4SReT6/Tck0Lc0DbYE10KjtxKlE wtU3q2hP7nrw== X-IronPort-AV: E=Sophos;i="5.81,278,1610438400"; d="scan'208";a="376922132" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 10:00:08 -0700 Date: Thu, 25 Mar 2021 10:02:36 -0700 From: Jacob Pan To: Jean-Philippe Brucker Cc: Jason Gunthorpe , LKML , Joerg Roedel , Lu Baolu , David Woodhouse , iommu@lists.linux-foundation.org, cgroups@vger.kernel.org, Tejun Heo , Li Zefan , Johannes Weiner , Jean-Philippe Brucker , Alex Williamson , Eric Auger , Jonathan Corbet , Raj Ashok , "Tian, Kevin" , Yi Liu , Wu Hao , Dave Jiang , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs Message-ID: <20210325100236.17241a1c@jacob-builder> In-Reply-To: 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> Organization: OTC X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jean-Philippe, On Thu, 25 Mar 2021 11:21:40 +0100, Jean-Philippe Brucker wrote: > 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? > Good point. Yes, you can get cgroup subsystem state in kernel_init for charging/uncharging. I would think module_init should work also since it is after kernel_init. I have tried the following: static int __ref kernel_init(void *unused) { int ret; + struct cgroup_subsys_state *css; + css = task_get_css(current, pids_cgrp_id); But that would imply: 1. IOASID has to be built-in, not as module 2. IOASIDs charged on PID1/init would not subject to cgroup limit since it will be in the root cgroup and we don't support migration nor will migrate. Then it comes back to the question of why do we try to limit in-kernel users per cgroup if we can't enforce these cases. > Thanks, > Jean > Thanks, Jacob