[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5415d383-5442-a127-bdab-fce9e9b7a3b2@linux.intel.com>
Date: Thu, 15 Sep 2022 11:00:21 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Ethan Zhao <haifeng.zhao@...ux.intel.com>, iommu@...ts.linux.dev
Cc: baolu.lu@...ux.intel.com, Joerg Roedel <joro@...tes.org>,
Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Kevin Tian <kevin.tian@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d: Enable PASID during iommu device probe
On 9/14/22 4:59 PM, Ethan Zhao wrote:
>>> What the error path would be if this code runs on some old platforms
>>> don't
>>>
>>> support PASID, would you print out "this platform doesn't suppor
>>> PASID" and
>>>
>>> give users an interface function to query if the PASID cap of iommu
>>> is enabled
>>>
>>> and if not why ?
>>
>> It's not an error case if the IOMMU doesn't support PASID. But it's an
>> error case if any device drivers call PASID related IOMMU interfaces
>> (for example, iommu_domain_attach/detach_dev_pasid()). The corresponding
>> error code will be returned to the drivers.
>>
> So iommu driver withdraws the flexibility/rights from device driver
> about the
>
> ability to enable PASID, looks much more *integrated* iommu works as
> relation
No. This patch doesn't withdraw anything. It's just a code refactoring.
>
> controller in device-iommu-domain by enabling PASID in iommu probe stage
>
> by default -- iommu decides to enable PASID or not though device-iommu-
>
> domain might not work ? or they should work because they are hard-wired
>
> together (device - iommu) even device is hotpluged later.
>
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.
Best regards,
baolu
Powered by blists - more mailing lists