linux-kernel - Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM

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]

Message-ID: <c8708b95-14b9-4545-84f7-6f45161456cc@linux.intel.com>
Date: Sat, 14 Sep 2024 13:49:44 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: "Tian, Kevin" <kevin.tian@...el.com>,
 "j.granados@...sung.com" <j.granados@...sung.com>,
 David Woodhouse <dwmw2@...radead.org>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
 Jason Gunthorpe <jgg@...pe.ca>, Klaus Jensen <its@...elevant.dk>
Cc: baolu.lu@...ux.intel.com,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v2 1/5] iommu/vt-d: Separate page request queue from SVM

On 2024/9/14 10:53, Tian, Kevin wrote:
>> From: Baolu Lu<baolu.lu@...ux.intel.com>
>> Sent: Saturday, September 14, 2024 9:18 AM
>>
>> On 9/14/24 8:52 AM, Tian, Kevin wrote:
>>>> From: Joel Granados via B4 Relay
>>>> <devnull+j.granados.samsung.com@...nel.org>
>>>>
>>>> From: Joel Granados<j.granados@...sung.com>
>>>>
>>>> IO page faults are no longer dependent on CONFIG_INTEL_IOMMU_SVM.
>>>> Move
>>>> all Page Request Queue (PRQ) functions that handle prq events to a new
>>>> file in drivers/iommu/intel/prq.c. The page_req_des struct is now
>>>> declared in drivers/iommu/intel/prq.c.
>>>>
>>>> No functional changes are intended. This is a preparation patch to
>>>> enable the use of IO page faults outside the SVM/PASID use cases.
>>> Do we want to guard it under a new config option e.g.
>>> CONFIG_INTEL_IOMMU_IOPF? it's unnecessary to allocate resources
>>> for the majority usages which don't require IOPF.
>>>
>>> Baolu?
>> The OS builder doesn't know if Linux will run on a platform with PRI-
>> capable devices. They'll probably always enable this option if we
>> provide it.
> hmm then why do we need a SVM option? In reality I haven't seen
> a platform which supports IOPF but no pasid/SVM. so the reason
> for whether to have an option should be same between IOPF/SVM.
> 
> IMHO the point of options is to allow reducing footprint of the kernel
> image and many options are probably always enabled in distributions...

To be honest, I would hope to remove the SVM option some day. It's
nothing special except listening to an external notification and
synchronize the caches when the page table is updated. It's common to
all cases where a page table is shared between the IOMMU and another
component.

As for CONFIG_INTEL_IOMMU_IOPF, my suggestion is that we don't need to
add any unnecessary options unless we see a real need.

Thanks,
baolu