linux-kernel - Re: [PATCH] irqchip/gic-v3-its: remove the shareability of ITS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJqh2TJvkk5o+MkET8UED-8AUhsDdehvsnR2+7bfeRoY7AmPdQ@mail.gmail.com>
Date:   Fri, 9 Dec 2022 11:34:21 +0800
From:   Harry Song <jundongsong1@...il.com>
To:     Sebastian Reichel <sebastian.reichel@...labora.com>
Cc:     Marc Zyngier <maz@...nel.org>, tglx@...utronix.de,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3-its: remove the shareability of ITS

Thank you for your reply. I know these two links.
My email is to ask about the root cause of this bug.

I would like to know whether the driver design of ITS requires that
the CPU and ITS
must be in a shared domain. Such as using CCI in chips;

>From marc's reply, I think so. In addition to CCI, other methods can
also be used to
ensure consistency, which is a requirement for IC design.

Thanks,
Harry

On Fri, Dec 9, 2022 at 12:58 AM Sebastian Reichel
<sebastian.reichel@...labora.com> wrote:
>
> Hi,
>
> On Thu, Dec 08, 2022 at 10:28:29AM +0800, Harry Song wrote:
> > On Wed, Dec 7, 2022 at 11:19 PM Marc Zyngier <maz@...nel.org> wrote:
> > >
> > > On Wed, 07 Dec 2022 13:52:23 +0000,
> > > Harry Song <jundongsong1@...il.com> wrote:
> > > >
> > > > I know this is a very wrong patch, but my platform
> > > > has an abnormal ITS problem caused by data consistency:
> > > > My chip does not support Cache Coherent Interconnect (CCI).
> > >
> > > That doesn't mean much. Nothing mandates to have a CCI, and plenty of
> > > systems have other ways to maintain coherency.
> > >
> > > > By default, ITS driver is the inner memory attribute.
> > > > gits_write_cbaser() is used to write the inner memory
> > > > attribute. But hw doesn't return the hardware's non-shareable
> > > > property,so I don't think reading GITS_CBASER and GICR_PROPBASER
> > > > here will get the real property of the current hardware: inner
> > > > or outer shareable is not supported, so I would like to know
> > > > whether ITS driver cannot be used on chips without CCI, or
> > > > what method can be used to use ITS driver on chips without CCI?
> > >
> > > It's not about CCI or not CCI. It is about which shareability domain
> > > your ITS is in.
> > >
> > > And it doesn't only affect the ITS. It also affects the
> > > redistributors, and anything that accesses memory.
> > >
> >
> > Yes, my current chip is Rockchip platform (rk3588), so is it because the chip
> > is not designed as a proper shared domain for ITS, so the exception of
> > ITS is caused?
> >
> > > >
> > > > The current patch is designed to make ITS think that the current
> > > > chip has no inner or outer memory properties, and then use
> > > > its by flushing dcache.
> > > >
> > > > This is the log for bug reports without patches:
> > > >
> > > > [    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000003460000
> > > > [    0.000000] ITS [mem 0x03440000-0x0345ffff]
> > > > [    0.000000] ITS@...000000003440000: allocated 8192 Devices @41850000 (indirect, esz 8, psz 64K, shr 0)
> > > > [    0.000000] ITS@...000000003440000: allocated 32768 Interrupt Collections @41860000 (flat, esz 2, psz 64K, shr 0)
> > > > [    0.000000] GICv3: using LPI property table @0x0000000041870000
> > > > [    0.000000] GICv3: CPU0: using allocated LPI pending table @0x0000000041880000
> > > > [    0.000000] ITS queue timeout (64 1)
> > > > [    0.000000] ITS cmd its_build_mapc_cmd failed
> > > > [    0.000000] ITS queue timeout (128 1)
> > > > [    0.000000] ITS cmd its_build_invall_cmd failed
> > >
> > > Ah, this suspiciously looks like a Rockchip machine...
> > >
> > > >
> > > > Signed-off-by: Harry Song <jundongsong1@...il.com>
> > > > ---
> > > >
> > > > I am very sorry to bother you. This problem has been bothering me
> > > > for several weeks.  I am looking forward to your reply.
> > >
> > > If you have such issue, this needs to be handled as per-platform
> > > quirk. I'm not putting such generic hacks in the driver.
> > >
> > >         M.
> > >
> > > --
> > > Without deviation from the norm, progress is not possible.
> >
> > Are there currently other chip platforms that have this problem, and then ITS
> > is already compatible with the problem? Please tell me how to submit
> > hacks patch for rk3588 platform?
> >
> > If the hacks patch cannot be submitted, please tell me whether it
> > requires the next generation
> > chip to have any design requirements for ITS?
> >
> > Design ITS and CPU to be the same inner memory property?
>
> Previous rockchip generation has the same bug and it got discussed
> here:
>
> https://lore.kernel.org/lkml/871rbdt4tu.wl-maz@kernel.org/T/#m5dbc70ff308d81e98dd0d797e23d3fbf9c353245
>
> You can use this DT as base with mainline to avoid ITS:
>
> https://lore.kernel.org/all/20221205172350.75234-1-sebastian.reichel@collabora.com/
>
> -- Sebastian