[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB52766161477C2540969C83568C242@BN9PR11MB5276.namprd11.prod.outlook.com>
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.
Powered by blists - more mailing lists