Given the "ewww" patch to make a module parameter workaround for this: https://lore.kernel.org/linux-wireless/20240321172402.346191-1-jtornosm@xxxxxxxxxx/T/#u On Tue, 2024-01-16 at 11:41 +0100, David Woodhouse wrote: > > How exactly is the content of this register then given back to the > firmware? Is that communication snoopable by the VMM? If I'm reading the code correctly, it's just a write to a register in a memory mapped region, possibly in multiple locations (different queues or something). Possibly indirect (see __ath11k_pcic_write32), but someone would have to trace it or know the HW better to understand which locations it's written to. But yeah seems totally feasible to just translate that back in the VMM. > > > Off hand I don't have a good solution for this, the hardware is > > > essentially imposing a unique requirement for MSI programming that the > > > driver needs visibility of the physical MSI address and data. > > > > > Strictly, the driver doesn't need visibility to the actual values used > by the hardware. Another way of it looking at it would be to say that > the driver programs the MSI through this non-standard method, it just > needs the VMM to trap and handle that, just as the VMM does for the > standard MSI table. Indeed. Much better than having a module parameter. > Which is what I thought we'd already seen on some Atheros devices. It probably also affects ath12k, seems similar. johannes
