On Wed, 07 Sep 2022 14:18:52 +0100,
"Radovanovic, Aleksandar" [off-list ref] wrote:

quoted

quoted

As Marc mentions, CDX
MSI writes are downstream of the SMMU and, if SMMU does not provide
identity mapping for GITS_TRANSLATER, then we have a problem and may
need to allow the OS to write the address part. However, even if we
did, the CDX hardware is limited in that it can only take one
GITS_TRANSLATER register target address per system, not per CDX
device, nor per MSI vector.

If the MSI generation is downstream of the SMMU, why should the SMMU
provide a 1:1 mapping for GITS_TRANSLATER? I don't think it should provide a
mapping at all in this case. But it looks like I don't really understand how
these things are placed relative to each other... :-/

Apologies, I got my streams confused. It is _upstream_ of the SMMU,
it does go through SMMU mapping.

OK, so you definitely need a mapping, but it cannot be a translation,
and it needs to be in all the possible address spaces. OMG.

quoted

quoted

As for the data part (EventID in GIC parlance), this is always going
to be the CDX device-relative vector number - I believe this can't be
changed, it is a hardware limitation (but I need to double-check).
That should be OK, though, as I believe this is exactly what Linux
would write anyway, as each CDX device should be in its own IRQ domain
(i.e. have its own ITS device table).

But that's really the worse part. You have hardcoded what is the
*current* Linux behaviour. Things change. And baking SW behaviour into a
piece of HW looks incredibly shortsighted...

For posterity, I'm not an RTL designer/architect, so share your
sentiment to a certain extent. That said, I expect the decision was
not based on Linux or any other SW behaviour, but because it is the
most straightforward and least expensive way to do it. Having an
EventID register for each and every MSI source just so you can
program it in any random order costs flops and all the associated
complexity of extra RTL logic (think timing closure, etc.), so
trade-offs are made. The fact that it matches current Linux
behaviour means we just got lucky...

Yeah, but that's not the only problem: there is no guarantee that we
have enough LPIs to allocate for the device, so we'll perform a
partial allocation (8 instead of 32 LPIs, for example).

How do you tell the device which events are valid? As far as I can
see, you can't, and I guess it will fire on all of them, resulting in
interrupts being dropped on the floor.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel