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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 345A5C433EF for ; Wed, 29 Sep 2021 22:53:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C31C6142A for ; Wed, 29 Sep 2021 22:53:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347249AbhI2WzY (ORCPT ); Wed, 29 Sep 2021 18:55:24 -0400 Received: from mga14.intel.com ([192.55.52.115]:55656 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344976AbhI2WzX (ORCPT ); Wed, 29 Sep 2021 18:55:23 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10122"; a="224714675" X-IronPort-AV: E=Sophos;i="5.85,334,1624345200"; d="scan'208";a="224714675" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2021 15:53:40 -0700 X-IronPort-AV: E=Sophos;i="5.85,334,1624345200"; d="scan'208";a="588270949" Received: from jacob-builder.jf.intel.com (HELO jacob-builder) ([10.7.199.155]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2021 15:53:40 -0700 Date: Wed, 29 Sep 2021 15:57:20 -0700 From: Jacob Pan To: Jason Gunthorpe Cc: iommu@lists.linux-foundation.org, LKML , Joerg Roedel , Christoph Hellwig , "Tian, Kevin" , Tony Luck , Dave Jiang , Raj Ashok , "Kumar, Sanjay K" , mike.campin@intel.com, Thomas Gleixner , jacob.jun.pan@linux.intel.com Subject: Re: [RFC 0/7] Support in-kernel DMA with PASID and SVA Message-ID: <20210929155720.794b6e65@jacob-builder> In-Reply-To: <20210929193953.GX964074@nvidia.com> References: <1632256181-36071-1-git-send-email-jacob.jun.pan@linux.intel.com> <20210929123437.721991dc@jacob-builder> <20210929193953.GX964074@nvidia.com> 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 Jason, On Wed, 29 Sep 2021 16:39:53 -0300, Jason Gunthorpe wrote: > On Wed, Sep 29, 2021 at 12:37:19PM -0700, Jacob Pan wrote: > > > For #2, it seems we can store the kernel PASID in struct device. This > > will preserve the DMA API interface while making it PASID capable. > > Essentially, each PASID capable device would have two special global > > PASIDs: > > - PASID 0 for DMA request w/o PASID, aka RID2PASID > > - PASID 1 (randomly selected) for in-kernel DMA request w/ > > PASID > > This seems reasonable, I had the same thought. Basically just have the > driver issue some trivial call: > pci_enable_pasid_dma(pdev, &pasid) That would work, but I guess it needs to be an iommu_ call instead of pci_? Or, it can be done by the platform IOMMU code where system PASID is automatically enabled for PASID capable devices during boot and stored in struct device. Device drivers can retrieve the PASID from struct device. I think your suggestion is more precise, in case the driver does not want to do DMA w/ PASID, we can do less IOTLB flush (PASID 0 only). > And then DMA tagged with the PASID will be handled equivilant to > untagged DMA. Basically PASID and no PASID point to the exact same IO > page table and the DMA API manipulates that single page table. > > Having multiple RID's pointing at the same IO page table is something > we expect iommufd to require so the whole thing should ideally fall > out naturally. That would be the equivalent of attaching multiple devices to the same IOMMU domain. right? > Jason Thanks, Jacob