Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <cbb2504c-cb6a-1334-2207-63a410cf6484@linux.intel.com>
Date:   Fri, 16 Sep 2022 12:01:20 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cc:     baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
        Will Deacon <will@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Kevin Tian <kevin.tian@intel.com>, linux-kernel@vger.kernel.org
Content-Language: en-US
To:     Ethan Zhao <haifeng.zhao@linux.intel.com>, iommu@lists.linux.dev
References: <20220912024826.1684913-1-baolu.lu@linux.intel.com>
 <046916aa-980c-c40d-1163-6ab839248201@linux.intel.com>
 <e0c43ca7-0ad3-a4d6-960b-9853bb815438@linux.intel.com>
 <e26efaee-d84a-3b60-8400-90d8e49a9b25@linux.intel.com>
 <5415d383-5442-a127-bdab-fce9e9b7a3b2@linux.intel.com>
 <78ec0fab-6f69-1d3d-86f3-84f159817707@linux.intel.com>
 <fc1f5412-6041-71b8-2a87-84f2f32456fc@linux.intel.com>
 <a6ac5953-7372-9894-58d4-d1ee2905d4dd@linux.intel.com>
From:   Baolu Lu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH 1/1] iommu/vt-d: Enable PASID during iommu device probe
In-Reply-To: <a6ac5953-7372-9894-58d4-d1ee2905d4dd@linux.intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2022/9/16 11:35, Ethan Zhao wrote:
> Baolu,
> 
> 在 2022/9/16 11:05, Baolu Lu 写道:
>> On 2022/9/16 10:40, Ethan Zhao wrote:
>>>>
>>>> I may not get you exactly. ???? Some IOMMU features reply on PASID
>>>> capabilities on both IOMMU and device. The IOMMU drivers enumerate the
>>>> capabilities and enable them if they are supported.
>>> I might not express it straightforward,  I mean with this patch iommu 
>>> deals with
>>>
>>> the complexity of enabling PASID (globally?)  or not at probing stage 
>>> , instead
>>>
>>> of other device driver side decision to request IOMMU PASID enabling 
>>> during
>>>
>>> their setup state.  if so you move the decision to iommu probe stage. 
>>> hmmm...
>>
>> I am sorry that the commit message was a bit confusing. Actually we
>> always enable PASID at iommu probe path w/ or w/o this patch.
> Really ?  the commit message is quit clear to me ~~@
>>
>>>
>>> Pros,  iommu driver controls everything about PASID enabling.
>>>
>>> Cons,  iommu driver handles all possible complexity about capability 
>>> matching
>>
>> Do device drivers need to configure PCI PASID without IOMMU? I searched
>> the tree and found nothing.
> 
> Device knows if it has PCI PASID cap and its driver also could determine 
> to request
> 
> iommu to enable PASID or not by invoking
> 
> intel_iommu_enable_sva()->*intel_iommu_enable_pasid()*

PASID is a PCIe capability. Though SVA is built on it,it's not only
for SVA. Thus, the purpose of intel_iommu_enable_sva() is not for
enabling PASID.

> 
> *that is the old style without this patch.

No. Without this patch, PASID is also enabled in probe path. Calling
intel_iommu_enable_pasid() in enabling SVA path is actually duplicate.

The commit message for this patch is not correct. It's my bad. :-)

> *
> 
> *Iommu driver of course  also knows if devices in its group related the 
> iommu
> *
> 
> *have PASID cap support or not by enumerating them from the ACPI DMAR.
> *
> 
> This is my understanding, correct me if wrong.
> 
> While configuring device PCI PASID cap is another thing, from kernel or 
> userland,
> 
> compatible with the iommu cap, works, or not work.  Could you prevent anyone
> 
> from doing that ?

I do not object to adding a common interface to enable/disable PASID if
any device driver needs to manage PASID by itself. Before that, there
is no need to add complexity in IOMMU subsystem for a non-existent
requirement.

Best regards,
baolu