Messages in this thread | | | Date | Mon, 20 Mar 2023 09:35:20 -0700 | From | Nicolin Chen <> | Subject | Re: [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user |
| |
On Mon, Mar 20, 2023 at 01:01:53PM -0300, Jason Gunthorpe wrote: > On Mon, Mar 20, 2023 at 08:28:05AM -0700, Nicolin Chen wrote: > > On Mon, Mar 20, 2023 at 10:11:54AM -0300, Jason Gunthorpe wrote: > > > On Sun, Mar 19, 2023 at 06:32:03PM -0700, Nicolin Chen wrote: > > > > > > > +struct iommu_hwpt_invalidate_arm_smmuv3 { > > > > + struct iommu_iova_range range; > > > > > > what is this? > > > > Not used. A copy-n-paste mistake :( > > > > > > > > > + __u64 cmd[2]; > > > > +}; > > > > > > You still have to do something with the SID. We can't just allow any > > > un-validated SID value - the driver has to check the incoming SID > > > against allowed SIDs for this iommufd_ctx > > > > Hmm, that's something "missing" even in the current design. > > > > Yet, most of the TLBI commands don't hold an SID field. So, > > the hypervisor only trapping a queue write-pointer movement > > cannot get the exact vSID for a TLBI command. What our QEMU > > code currently does is simply broadcasting all the devices > > on the list of attaching devices to the vSMMU, which means > > that such an enforcement in the kernel would basically just > > allow any vSID (device) that's attached to the domain? > > SID is only used for managing the ATC as far as I know. It is because > the ASID doesn't convey enough information to determine what PCI RID > to generate an ATC invalidation for.
Yes. And a CD invalidation too, though the kernel eventually would do a broadcast to all devices that are using the same CD.
> We shouldn't be broadcasting for efficiency, at least it should not be > baked into the API. > > You need to know what devices the vSID is targetting ang issues > invalidations only for those devices.
I agree with that, yet cannot think of a solution to achieve that out of vSID. QEMU code by means of emulating a physical SMMU only reads the commands from the queue, without knowing which device (vSID) actually sent these commands.
I probably can do something to the solution that is doing an entire broadcasting, with the ASID fields from the commands, yet it'd only improve the situation by having an ASID-based broadcasting...
Thanks Nic
| |