linux-kernel - RE: [PATCH 1/8] iommu: Introduce a replace API for device pasid

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: Mon, 11 Mar 2024 09:26:14 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Liu, Yi L" <yi.l.liu@...el.com>, Jason Gunthorpe <jgg@...dia.com>
CC: "joro@...tes.org" <joro@...tes.org>, "alex.williamson@...hat.com"
	<alex.williamson@...hat.com>, "robin.murphy@....com" <robin.murphy@....com>,
	"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>, "cohuck@...hat.com"
	<cohuck@...hat.com>, "eric.auger@...hat.com" <eric.auger@...hat.com>,
	"nicolinc@...dia.com" <nicolinc@...dia.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
	"chao.p.peng@...ux.intel.com" <chao.p.peng@...ux.intel.com>,
	"yi.y.sun@...ux.intel.com" <yi.y.sun@...ux.intel.com>, "peterx@...hat.com"
	<peterx@...hat.com>, "jasowang@...hat.com" <jasowang@...hat.com>,
	"shameerali.kolothum.thodi@...wei.com"
	<shameerali.kolothum.thodi@...wei.com>, "lulu@...hat.com" <lulu@...hat.com>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>, "Duan,
 Zhenzhong" <zhenzhong.duan@...el.com>, "joao.m.martins@...cle.com"
	<joao.m.martins@...cle.com>, "Zeng, Xin" <xin.zeng@...el.com>, "Zhao, Yan Y"
	<yan.y.zhao@...el.com>
Subject: RE: [PATCH 1/8] iommu: Introduce a replace API for device pasid

> From: Liu, Yi L <yi.l.liu@...el.com>
> Sent: Sunday, March 10, 2024 9:06 PM
> 
> On 2024/1/16 01:19, Jason Gunthorpe wrote:
> > On Sun, Nov 26, 2023 at 10:34:21PM -0800, Yi Liu wrote:
> >> +int iommu_replace_device_pasid(struct iommu_domain *domain,
> >> +			       struct device *dev, ioasid_t pasid)
> >> +{
> >> +	struct iommu_group *group = dev->iommu_group;
> >> +	struct iommu_domain *old_domain;
> >> +	int ret;
> >> +
> >> +	if (!domain)
> >> +		return -EINVAL;
> >> +
> >> +	if (!group)
> >> +		return -ENODEV;
> >> +
> >> +	mutex_lock(&group->mutex);
> >> +	__iommu_remove_group_pasid(group, pasid);
> >
> > It is not replace if you do remove first.
> >
> > Replace must just call set_dev_pasid and nothing much else..
> 
> Seems uneasy to do it so far. The VT-d driver needs to get the old domain
> first in order to do replacement. However, VT-d driver does not track the
> attached domains of pasids. It gets domain of a pasid
> by iommu_get_domain_for_dev_pasid(). Like
> intel_iommu_remove_dev_pasid)
> in link [1]. While the iommu layer exchanges the domain in the
> group->pasid_array before calling into VT-d driver. So when calling into
> VT-d driver, the domain got by iommu_get_domain_for_dev_pasid() is
> already
> the new domain. To solve it, we may need to let VT-d driver have its
> own tracking on the domains. How about your thoughts? @Jason, @Kevin,
> @Baoplu?
> 
> [1]
> https://github.com/torvalds/linux/blob/master/drivers/iommu/intel/iommu
> .c#L4621C19-L4621C20
> 

Jason's point was that the core helper should directly call set_dev_pasid
and underlying iommu driver decides whether atomic replacement
can be implemented inside the callback. If you first remove in the core
then one can never implement a replace semantics.