Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 17 Mar 2023 07:16:14 -0700 | From | Nicolin Chen <> | Subject | Re: [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user |
| |
On Fri, Mar 17, 2023 at 09:47:47AM +0000, Tian, Kevin wrote: > External email: Use caution opening links or attachments > > > > From: Robin Murphy <robin.murphy@arm.com> > > Sent: Thursday, March 9, 2023 10:49 PM > > > + case CMDQ_OP_ATC_INV: > > > + ssid = inv_info->ssid; > > > + iova = inv_info->range.start; > > > + size = inv_info->range.last - inv_info->range.start + 1; > > > + break; > > > > Can we do any better than multiplying every single ATC_INV command, even > > for random bogus StreamIDs, into multiple commands across every physical > > device? In fact, I'm not entirely confident this isn't problematic, if > > the guest wishes to send invalidations for one device specifically while > > it's put some other device into a state where sending it a command would > > do something bad. At the very least, it's liable to be confusing if the > > guest sends a command for one StreamID but gets an error back for a > > different one. > > > > Or do we need support this cmd at all? > > For vt-d we always implicitly invalidate ATC following a iotlb invalidation > request from userspace. Then vIOMMU just treats it as a nop in the > virtual queue. > > IMHO a sane iommu driver should always invalidate both iotlb and atc > together. I'm not sure a valid usage where iotlb is invalidated while > atc is left with some stale mappings.
vSMMU code in QEMU actually doesn't forward this command. So, I guess that you are right about this support here and we may just drop it.
Thanks! Nic
| ![\](/images/icornerr.gif) |