Linux IOMMU Development
 help / color / mirror / Atom feed
From: Ethan Zhao <haifeng.zhao@linux.intel.com>
To: Baolu Lu <baolu.lu@linux.intel.com>, iommu@lists.linux.dev
Cc: 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
Subject: Re: [PATCH 1/1] iommu/vt-d: Enable PASID during iommu device probe
Date: Fri, 16 Sep 2022 11:37:54 +0800	[thread overview]
Message-ID: <27483599-d0fd-ce07-1a14-c6d68e6d364f@linux.intel.com> (raw)
In-Reply-To: <fc1f5412-6041-71b8-2a87-84f2f32456fc@linux.intel.com>


在 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()*

*that is the old style without this patch.
*

*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 ?


Thanks,

Ethan
>
> Best regards,
> baolu

-- 
"firm, enduring, strong, and long-lived"


  reply	other threads:[~2022-09-16  3:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-12  2:48 [PATCH 1/1] iommu/vt-d: Enable PASID during iommu device probe Lu Baolu
2022-09-13  3:13 ` Tian, Kevin
2022-09-13  6:01   ` Baolu Lu
2022-09-13  7:42     ` Tian, Kevin
2022-09-13  7:46 ` Ethan Zhao
2022-09-13  9:30   ` Baolu Lu
     [not found]     ` <e26efaee-d84a-3b60-8400-90d8e49a9b25@linux.intel.com>
2022-09-15  3:00       ` Baolu Lu
2022-09-16  2:40         ` Ethan Zhao
2022-09-16  3:05           ` Baolu Lu
2022-09-16  3:37             ` Ethan Zhao [this message]
     [not found]             ` <a6ac5953-7372-9894-58d4-d1ee2905d4dd@linux.intel.com>
2022-09-16  4:01               ` Baolu Lu
2022-09-13  8:01 ` Tian, Kevin
2022-09-13  9:25   ` Baolu Lu
2022-09-15  3:22     ` Tian, Kevin
2022-09-15  7:21       ` Baolu Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27483599-d0fd-ce07-1a14-c6d68e6d364f@linux.intel.com \
    --to=haifeng.zhao@linux.intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox