From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EA08AD52 for ; Mon, 13 Feb 2023 21:40:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676324423; x=1707860423; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fjiKvrHISbinyt7S0bRErJ7/aoSEHDwLa1AouQtc4WM=; b=QifnvOeLvzgpNk4aMCjJXFXBrhFHvsjIjh876fqizbAH9ZsUdVl7YoVv Vl8gefkPWM53yBrmfE4UzylhW/1Kf80zpsVC7JyxdhR2Bl+j5yk3PvQ7r KKIWFn0LM4DpXBlgvxFLpywj8DXol3wkMZjXoq+W05E3bXa9jSsJwNLkE N3O3nJaUuGuUIVX9Gxdd+hMOYHgNvb7pGtVPM6b5I2qPddaCi8iSnV52r nITk3mD4i92pmgkL5+Z32npjFTIQgd621hQMCKMg7jgT3XfQIFex2qVS5 oM/f8PopJQ22ROiJE4+ZDTbScuptMhNPvVl6NetuvFpvJf2JqfbU9C2UA A==; X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="314652771" X-IronPort-AV: E=Sophos;i="5.97,294,1669104000"; d="scan'208";a="314652771" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2023 13:40:22 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10620"; a="646534746" X-IronPort-AV: E=Sophos;i="5.97,294,1669104000"; d="scan'208";a="646534746" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.24.100.114]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Feb 2023 13:40:22 -0800 Date: Mon, 13 Feb 2023 13:44:02 -0800 From: Jacob Pan To: Jason Gunthorpe Cc: Jean-Philippe Brucker , LKML , iommu@lists.linux.dev, Lu Baolu , Joerg Roedel , Jean-Philippe Brucker , Robin Murphy , David Woodhouse , Raj Ashok , "Tian, Kevin" , Yi Liu , jacob.jun.pan@linux.intel.com Subject: Re: [PATCH 2/2] iommu/ioasid: Remove custom IOASID allocator Message-ID: <20230213134402.194ed7fd@jacob-builder> In-Reply-To: References: <20230210230206.3160144-1-jacob.jun.pan@linux.intel.com> <20230210230206.3160144-3-jacob.jun.pan@linux.intel.com> <20230213103455.02f3ac37@jacob-builder> Organization: OTC X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Jason, On Mon, 13 Feb 2023 15:39:19 -0400, Jason Gunthorpe wrote: > On Mon, Feb 13, 2023 at 10:34:55AM -0800, Jacob Pan wrote: > > Hi Jean-Philippe, > > > > On Mon, 13 Feb 2023 16:20:29 +0000, Jean-Philippe Brucker > > wrote: > > > > > On Fri, Feb 10, 2023 at 03:02:06PM -0800, Jacob Pan wrote: > > > > Custom allocator feature was introduced to support VT-d's virtual > > > > command, an enlightened interface designed for VMs to allocate > > > > PASIDs from the host. > > > > > > > > As we remove/withdraw the VT-d virtual command feature, the sole > > > > user of custom allocator, we can safely remove the custom allocator > > > > as well. Effectively, this will return IOASID core to the original > > > > simple global namespace allocator. > > > > > > > > Signed-off-by: Jacob Pan > > > > > > You can also drop the spinlock.h include. With that: > > > > > good catch, thanks > > > Reviewed-by: Jean-Philippe Brucker > > > > > > On a related note, it looks like 100b8a14a370 ("iommu/vt-d: Add pasid > > > private data helpers") removed the last user of ioasid_set_data(). I > > > guess that could be dropped too, unless you plan to still use it? > > > > > You are right, will remove. > > I was planning on the other way around which will convert VT-d's private > > pasid data helpers to common ioasid code, but when I look closer the > > private pasid xa is just holding a list of pasid/mm which could be per > > iommu not global. Another cleanup I suppose. > > Please lets just delete this entire ioasid thing, it has no purpose > anymore at all. > > I did a sketch on how it do it here: > > https://github.com/jgunthorpe/linux/commits/iommu_remove_ioasid > > I wasn't very careful or elegant with the last patch, can you tidy it > up and repost this as your v2? > yes, will do. > Your DMA API PASID thing will simply need one new API to alloc/free a > PASID from the iommu_global_pasid_ida It should satisfy what we need right now. Just wondering if we were to do resource management of global PASIDs, say with the new misc cgroup controller, do we plan to expand in iommu sva code? If yes, do we keep DMA API PASID in a separate range/set? Thanks, Jacob