[RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its domain as parent
Marc Zyngier
maz at kernel.org
Wed Sep 7 05:14:54 PDT 2022
On Wed, 07 Sep 2022 12:33:12 +0100,
Robin Murphy <robin.murphy at arm.com> wrote:
>
> On 2022-09-07 12:17, Marc Zyngier wrote:
> > On Tue, 06 Sep 2022 18:19:06 +0100,
> > Jason Gunthorpe <jgg at nvidia.com> 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.
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.
More information about the linux-arm-kernel
mailing list