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