lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 16 Sep 2022 10:40:09 +0800
From:   Ethan Zhao <haifeng.zhao@...ux.intel.com>
To:     Baolu Lu <baolu.lu@...ux.intel.com>, iommu@...ts.linux.dev
Cc:     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


在 2022/9/15 11:00, Baolu Lu 写道:
>
>
> 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.
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...

Pros,  iommu driver controls everything about PASID enabling.

Cons,  iommu driver handles all possible complexity about capability 
matching

etc.


Thanks,

Ethan

>
> Best regards,
> baolu

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ