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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9DCCC4332F for ; Thu, 9 Dec 2021 17:04:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242260AbhLIRI1 (ORCPT ); Thu, 9 Dec 2021 12:08:27 -0500 Received: from mga14.intel.com ([192.55.52.115]:15342 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242240AbhLIRIR (ORCPT ); Thu, 9 Dec 2021 12:08:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1639069484; x=1670605484; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Hu8IWPpqaYWvoYRfgiAlV+K8HC4bEA3MgGocGhWIN5c=; b=cnPpKmE8uJvpl04n1S0IalkrR3ZBbtnZYBLUoaFaDMlPfYjWI7IlfGbp msiXKE7/tY5/GElktNly1UMmd4x6ldqx2z0jqSuGKuO015sMQ6odsvQrV 5u4sk4crmUcwMEYma5KwnqA12ew3gZYXk4dA7Z1sVhZoxu9PHrfvgnVbT dZndxtqGkytgA+VAuSRf3IuSLxCLNrX09y5z4YP6REF9BwHuWqmu7HyWN ubeBPrFtwiCUICUu3u08XtQUYqzQIJZPxOuXqGVDZbacHkmCdfd3FdObH VgCs2sdDUXqJLlYw3jIl607l155vSLx4H85GAt9ZXr1yWpXcQfykHUEHO A==; X-IronPort-AV: E=McAfee;i="6200,9189,10193"; a="238377763" X-IronPort-AV: E=Sophos;i="5.88,193,1635231600"; d="scan'208";a="238377763" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2021 09:01:33 -0800 X-IronPort-AV: E=Sophos;i="5.88,193,1635231600"; d="scan'208";a="503566698" Received: from otc-nc-03.jf.intel.com (HELO otc-nc-03) ([10.54.39.123]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Dec 2021 09:01:32 -0800 Date: Thu, 9 Dec 2021 08:57:15 -0800 From: "Raj, Ashok" To: Jacob Pan Cc: Lu Baolu , "Tian, Kevin" , "iommu@lists.linux-foundation.org" , LKML , Joerg Roedel , Jason Gunthorpe , Christoph Hellwig , Greg Kroah-Hartman , Jean-Philippe Brucker , "Pan, Jacob jun" , "Kumar, Sanjay K" , "Jiang, Dave" , "Luck, Tony" , "Liu, Yi L" , Barry Song <21cnbao@gmail.com>, "Zanussi, Tom" , "Williams, Dan J" , Ashok Raj Subject: Re: [PATCH 2/4] iommu: Add PASID support for DMA mapping API users Message-ID: <20211209165715.GA566788@otc-nc-03> References: <1638884834-83028-1-git-send-email-jacob.jun.pan@linux.intel.com> <1638884834-83028-3-git-send-email-jacob.jun.pan@linux.intel.com> <16408193-c8bc-3046-b32f-9274bf0b415c@linux.intel.com> <20211208104939.732fa5b9@jacob-builder> <1b3ee13d-0148-1156-52ad-b96bca51cb6f@linux.intel.com> <20211209083249.7d775512@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211209083249.7d775512@jacob-builder> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 09, 2021 at 08:32:49AM -0800, Jacob Pan wrote: > Hi Lu, > > On Thu, 9 Dec 2021 10:21:38 +0800, Lu Baolu > wrote: > > > On 12/9/21 9:56 AM, Tian, Kevin wrote: > > >> From: Jacob Pan > > >> Sent: Thursday, December 9, 2021 2:50 AM > > >> > > >>> Can a device issue DMA requests with PASID even there's no system > > >> IOMMU > > >>> or the system IOMMU is disabled? > > >>> > > >> Good point. > > >> If IOMMU is not enabled, device cannot issue DMA requests with PASID. > > >> This API will not be available. Forgot to add dummy functions to the > > >> header. > > > > > > PASID is a PCI thing, not defined by IOMMU. True, but RP is just a forwarding agent on these EETLP prefixes. I'm not sure how RP's will behave if they receive a TLP they don't understand and I suspect they might pull the system down via some UR type response when IOMMU isn't enabled. > > > > > > I think the key is physically if IOMMU is disabled, how will root > > > complex handle a PCI memory request including a PASID TLP prefix? Does > > > it block such request due to no IOMMU to consume PASID or simply ignore > > > PASID and continue routing the request to the memory controller? > > > > > > If block, then having an iommu interface makes sense. > > > > > > If ignore, possibly a DMA API call makes more sense instead, implying > > > that this extension can be used even when iommu is disabled. > > > > > > I think that is what Baolu wants to point out. > > > Thanks for clarifying, very good point. > Looking at the PCIe spec. I don't see specific rules for RC to ignore or > block PASID TLP if not enabled. > "- A Root Complex that supports PASID TLP Prefixes must have a device > specific mechanism for enabling them. By default usage of PASID TLP > Prefixes is disabled > - Root Complexes may optionally support TLPs with PASID TLP Prefixes. The > mechanism used to detect whether a Root Complex supports the PASID TLP > Prefix is implementation specific Isn't implementation specific mechanism is IOMMU? > " > For all practical purposes, why would someone sets up PASID for DMA just to > be ignored? An IOMMU interface makes sense to me. > > > Yes, exactly. Imagining in the VM guest environment, do we require a > > vIOMMU for this functionality? vIOMMU is not performance friendly if we > > put aside the security considerations. > > > The primary use case for accelerators to use in-kernel DMA will be in > pass-through mode. vIOMMU should be able to do PT with good performance, > right? no nesting, IO page faults. But from an enabling perspective when PASID is in use we have to mandate either the presence of an IOMMU, or some hypercall that will do the required plumbing for PASID isn't it?