On Wed, 07 Sep 2022 12:33:12 +0100,
Robin Murphy [off-list ref] wrote:

On 2022-09-07 12:17, Marc Zyngier wrote:

quoted

On Tue, 06 Sep 2022 18:19:06 +0100,
Jason Gunthorpe [off-list ref] wrote:

quoted

On Tue, Sep 06, 2022 at 07:17:58PM +0530, Nipun Gupta wrote:

quoted

+static void cdx_msi_write_msg(struct irq_data *irq_data,
+			      struct msi_msg *msg)
+{
+	/*
+	 * Do nothing as CDX devices have these pre-populated
+	 * in the hardware itself.
+	 */
+}

Huh?

There is no way it can be pre-populated, the addr/data pair,
especially on ARM, is completely under SW control.

There is nothing in the GIC spec that says that.

quoted

There is some commonly used IOVA base in Linux for the ITS page, but
no HW should hardwire that.

That's not strictly true. It really depends on how this block is
integrated, and there is a number of existing blocks that know *in HW*
how to signal an LPI.

See, as the canonical example, how the mbigen driver doesn't need to
know about the address of GITS_TRANSLATER.

Yes, this messes with translation (the access is downstream of the
SMMU) if you relied on it to have some isolation, and it has a "black
hole" effect as nobody can have an IOVA that overlaps with the
physical address of the GITS_TRANSLATER register.

But is it illegal as per the architecture? No. It's just stupid.

If that were the case, then we'd also need a platform quirk so the
SMMU driver knows about it. Yuck.

Yup. As I said, this is stupid.

But even then, are you suggesting there is some way to convince the
ITS driver to allocate a specific predetermined EventID when a driver
requests an MSI? Asking for a friend...

Of course not. Whoever did that has decided to hardcode the Linux
behaviour into the HW, because it is well known that SW behaviour
never changes. Nononono.

I am >this< tempted to sneak a change into the allocation scheme to
start at 5 or 13 (alternatively), and to map LPIs top-down. That
should get people thinking.

Cheers,

	M.

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