Messages in this thread | | | Date | Mon, 20 Mar 2023 13:46:52 -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 03:07:13PM -0300, Jason Gunthorpe wrote: > On Mon, Mar 20, 2023 at 09:35:20AM -0700, Nicolin Chen wrote: > > > > 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. > > Huh? > > CMD_ATC_INV has the SID > > Other commands have the ASID. > > You never need to cross an ASID to a SID or vice versa. > > If the guest is aware of ATS it will issue CMD_ATC_INV with vSIDs, and > the hypervisor just needs to convert vSID to pSID. > > Otherwise vSID doesn't matter because it isn't used in the invalidation > API and you are just handling ASIDs that only need the VM_ID scope > applied.
Yea, I was thinking of your point (at the top) how we could ensure if an invalidation is targeting a correct vSID. So, that narrative was only about CMD_ATC_INV...
Actually, we don't forward CMD_ATC_INV in QEMU. In another thread, Kevin also remarked whether we need to support that in the host or not. And I plan to drop CMD_ATC_INV from the list of cache_invalidate_user(), following his comments and the QEMU situation. Our uAPI, either forwarding the commands or a package of queue info, should be able to cover this in the future whenever we think it's required.
Combining the two parts above, we probably don't need to know at this moment which vSID an invalidation is targeting, nor to only allow it to execute for those devices, since the rest of commands are all ASID based.
Thanks Nic
| |