On Tue, Jul 01, 2025 at 03:07:57PM -0700, Nicolin Chen wrote: > On Tue, Jul 01, 2025 at 08:43:30PM +0000, Pranjal Shrivastava wrote: > > On Tue, Jul 01, 2025 at 01:23:17PM -0700, Nicolin Chen wrote: > > > Or perhaps calling them "non-accelerated commands" would be nicer. > > > > Uhh okay, so there'll be a separate driver in the VM issuing invalidation > > commands directly to the CMDQV thus we don't see any of it's part here? > > That's how it works. VM must run a guest-level VCMDQ driver that > separates accelerated and non-accelerated commands as it already > does: > > accelerated commands => VCMDQ (HW) > non-accelerated commands => SMMU CMDQ (SW) =iommufd=> SMMU CMDQ (HW) > Right exactly what got me confused. I was assuming the same CMDQV driver would run in the Guest kernel but seems like there's another driver for the Guest that's not in tree yet or maybe is a purely user-space thing? And the weird part was that "invalidation" commands are accelerated but we use the .cache_invalidate viommu op for `non-invalidation` commands. But I guess what you meant there could be non-accelerated invalidation commands (maybe something stage 2 TLBIs?) which would go through the .cache_invalidate op, right? > Nicolin Praan
