Re: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its domain as parent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux