linux-kernel - Re: [PATCH v2 1/6] iommu: Generic support for RMRs during device release

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: <99d27f65-4797-401f-a374-b3fccd67cdac@linux.intel.com>
Date: Thu, 23 Oct 2025 12:43:02 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Nicolin Chen <nicolinc@...dia.com>, joro@...tes.org, jgg@...dia.com,
 kevin.tian@...el.com
Cc: suravee.suthikulpanit@....com, will@...nel.org, robin.murphy@....com,
 sven@...nel.org, j@...nau.net, robin.clark@....qualcomm.com,
 m.szyprowski@...sung.com, krzk@...nel.org, dwmw2@...radead.org,
 yong.wu@...iatek.com, matthias.bgg@...il.com,
 angelogioacchino.delregno@...labora.com, tjeznach@...osinc.com,
 pjw@...nel.org, palmer@...belt.com, aou@...s.berkeley.edu, heiko@...ech.de,
 schnelle@...ux.ibm.com, mjrosato@...ux.ibm.com, orsonzhai@...il.com,
 baolin.wang@...ux.alibaba.com, wens@...e.org, jernej.skrabec@...il.com,
 samuel@...lland.org, thierry.reding@...il.com, jonathanh@...dia.com,
 jean-philippe@...aro.org, iommu@...ts.linux.dev,
 linux-kernel@...r.kernel.org, asahi@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org,
 linux-samsung-soc@...r.kernel.org, linux-mediatek@...ts.infradead.org,
 linux-riscv@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-s390@...r.kernel.org, linux-sunxi@...ts.linux.dev,
 linux-tegra@...r.kernel.org, virtualization@...ts.linux.dev,
 patches@...ts.linux.dev
Subject: Re: [PATCH v2 1/6] iommu: Generic support for RMRs during device
 release

On 10/23/25 10:21, Nicolin Chen wrote:
> From: Jason Gunthorpe<jgg@...dia.com>
> 
> Generally an IOMMU driver should leave the translation as BLOCKED until the
> translation entry is probed onto a struct device. When the struct device is
> removed, the translation should be put back to BLOCKED.
> 
> Drivers that are able to work like this can set their release_domain to the
> blocking domain, and the core code handles this work.
> 
> The exception is when the device has an IOMMU_RESV_DIRECT region, in which
> case the OS should continuously allow translations for the given range. And
> the core code generally prevents using a BLOCKED domain with this device.
> 
> Continue this logic for the device release and hoist some open coding from
> drivers. If the device has dev->iommu->require_direct and the driver uses a
> BLOCKED release_domain, override it to IDENTITY to preserve the semantics.
> 
> The only remaining required driver code for IOMMU_RESV_DIRECT should preset
> an IDENTITY translation during early IOMMU startup for those devices.
> 
> Signed-off-by: Jason Gunthorpe<jgg@...dia.com>
> Signed-off-by: Nicolin Chen<nicolinc@...dia.com>
> ---
>   drivers/iommu/iommu.c | 16 ++++++++++++++--
>   1 file changed, 14 insertions(+), 2 deletions(-)

Reviewed-by: Lu Baolu <baolu.lu@...ux.intel.com>