[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZBtrs3UHK55UUNYe@Asurada-Nvidia>
Date: Wed, 22 Mar 2023 13:57:23 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Robin Murphy <robin.murphy@....com>, <will@...nel.org>,
<eric.auger@...hat.com>, <kevin.tian@...el.com>,
<baolu.lu@...ux.intel.com>, <joro@...tes.org>,
<shameerali.kolothum.thodi@...wei.com>, <jean-philippe@...aro.org>,
<linux-arm-kernel@...ts.infradead.org>, <iommu@...ts.linux.dev>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 14/14] iommu/arm-smmu-v3: Add
arm_smmu_cache_invalidate_user
On Mon, Mar 20, 2023 at 07:19:34PM -0300, Jason Gunthorpe wrote:
> > IIUIC, the ioctl for the link of vSID/dev_id should happen at
> > the stage when boot boots, while the HWPT alloc ioctl happens
> > at CFGI_STE.
>
> Yes
>
> > > > What could be a good prototype of the ioctl? Would it be a VFIO
> > > > device one or IOMMUFD one?
> > >
> > > If we load the vSID table it should be a iommufd one, linked to the
> > > ARM SMMUv3 driver and probably take in a pointer to an array of
> > > vSID/dev_id pairs. Maybe an add/remove type of operation.
> >
> > Will try some solution.
>
> It is only necessary if you want to do batching
>
> For non-batching the SID invalidation should be done differently with
> a device_id input instead. That is a bit tricky to organize as you
> want iommufd to get back a 'struct device *' from the ID.
I am wondering whether we need to have dev_id, i.e. IOMMUFD,
in play with the link of pSID<->vSID, as I am thinking of a
simplified approach by passing the vSID via the hwpt alloc
structure when we allocate an S2 domain.
The arm_smmu_domain_alloc_user() takes this vSID and a dev
pointer, so it can easily tie the vSID to the dev's pSID.
By doing so, we wouldn't need a new ioctl anymore.
Thanks
Nic
Powered by blists - more mailing lists