linux-kernel - RE: [PATCH v1 02/20] iommu: Introduce a test

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: <BN9PR11MB527638C0E43E8AA000410B878CC5A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Wed, 5 Nov 2025 06:57:31 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Nicolin Chen <nicolinc@...dia.com>
CC: "joro@...tes.org" <joro@...tes.org>, "suravee.suthikulpanit@....com"
	<suravee.suthikulpanit@....com>, "will@...nel.org" <will@...nel.org>,
	"robin.murphy@....com" <robin.murphy@....com>, "sven@...nel.org"
	<sven@...nel.org>, "j@...nau.net" <j@...nau.net>, "jean-philippe@...aro.org"
	<jean-philippe@...aro.org>, "robin.clark@....qualcomm.com"
	<robin.clark@....qualcomm.com>, "dwmw2@...radead.org" <dwmw2@...radead.org>,
	"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>, "yong.wu@...iatek.com"
	<yong.wu@...iatek.com>, "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>, "tjeznach@...osinc.com"
	<tjeznach@...osinc.com>, "pjw@...nel.org" <pjw@...nel.org>,
	"palmer@...belt.com" <palmer@...belt.com>, "aou@...s.berkeley.edu"
	<aou@...s.berkeley.edu>, "heiko@...ech.de" <heiko@...ech.de>,
	"schnelle@...ux.ibm.com" <schnelle@...ux.ibm.com>, "mjrosato@...ux.ibm.com"
	<mjrosato@...ux.ibm.com>, "wens@...e.org" <wens@...e.org>,
	"jernej.skrabec@...il.com" <jernej.skrabec@...il.com>, "samuel@...lland.org"
	<samuel@...lland.org>, "thierry.reding@...il.com" <thierry.reding@...il.com>,
	"jonathanh@...dia.com" <jonathanh@...dia.com>, "iommu@...ts.linux.dev"
	<iommu@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "asahi@...ts.linux.dev"
	<asahi@...ts.linux.dev>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, "linux-rockchip@...ts.infradead.org"
	<linux-rockchip@...ts.infradead.org>, "linux-s390@...r.kernel.org"
	<linux-s390@...r.kernel.org>, "linux-sunxi@...ts.linux.dev"
	<linux-sunxi@...ts.linux.dev>, "linux-tegra@...r.kernel.org"
	<linux-tegra@...r.kernel.org>, "virtualization@...ts.linux.dev"
	<virtualization@...ts.linux.dev>, "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>
Subject: RE: [PATCH v1 02/20] iommu: Introduce a test_dev domain op and an
 internal helper

> From: Jason Gunthorpe <jgg@...dia.com>
> Sent: Tuesday, November 4, 2025 2:54 AM
> 
> On Thu, Oct 30, 2025 at 12:43:59PM -0700, Nicolin Chen wrote:
> 
> > FWIW, I am thinking of another design based on Jason's remarks:
> > https://lore.kernel.org/linux-iommu/aQBopHFub8wyQh5C@Asurada-
> Nvidia/
> >
> > So, instead of core initiating the round trip between the blocking
> > domain and group->domain, it forwards dev_reset_prepare/done to the
> > driver where it does a low-level attachment that wouldn't fail:
> >   For SMMUv3, it's an STE update.
> >   For intel_iommu, it seems to be the context table update?
> 
> Kevin, how bad do you think the UAPI issue is if we ignore it?
> 

yeah probably better to leave it. I didn't see a clean way and the
value didn't justify the complexity.

Regarding to PF reset, it's a devastating operation while the vf user
is operating the vf w/o any awareness. there must be certain
coordination in userspace. otherwise nobody can recover the
registers. Comparing to that, solving the domain attach problem
is less important...