On 2022-09-07 12:17, Marc Zyngier wrote:
On Tue, 06 Sep 2022 18:19:06 +0100,
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
On Tue, Sep 06, 2022 at 07:17:58PM +0530, Nipun Gupta wrote:
+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.
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.
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...
Cheers,
Robin.
