lkml.org 
[lkml]   [2022]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its domain as parent
On Tue, 06 Sep 2022 18:19:06 +0100,
Jason Gunthorpe <jgg@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.

M.

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

\
 
 \ /
  Last update: 2022-09-07 13:18    [W:0.162 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site