linux-kernel - Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support

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]

Date:   Thu, 09 Jun 2022 12:54:52 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     "Jiaxun Yang" <jiaxun.yang@...goat.com>
Cc:     "Dragan Mladjenovic" <Dragan.Mladjenovic@...mia.com>,
        "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
        "Chao-ying Fu" <cfu@...ecomp.com>,
        "Daniel Lezcano" <daniel.lezcano@...aro.org>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        "Greg Ungerer" <gerg@...nel.org>,
        "Hauke Mehrtens" <hauke@...ke-m.de>,
        "Ilya Lipnitskiy" <ilya.lipnitskiy@...il.com>,
        linux-kernel@...r.kernel.org,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "paulburton@...nel.org" <paulburton@...nel.org>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "Serge Semin" <fancer.lancer@...il.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Tiezhu Yang" <yangtiezhu@...ngson.cn>
Subject: Re: [PATCH v2 06/12] irqchip: mips-gic: Multi-cluster support

On Thu, 09 Jun 2022 11:14:01 +0100,
"Jiaxun Yang" <jiaxun.yang@...goat.com> wrote:
> 
> 
> 
> 在2022年6月8日六月 上午7:05，Marc Zyngier写道：
> > On Tue, 07 Jun 2022 19:23:02 +0100,
> > Jiaxun Yang <jiaxun.yang@...goat.com> wrote:
> >> 
> >> 
> >> 
> >> 在 2022/6/6 12:47, Marc Zyngier 写道:
> >> > On Wed, 25 May 2022 13:10:24 +0100,
> >> > Dragan Mladjenovic <Dragan.Mladjenovic@...mia.com> wrote:
> >> >> From: Paul Burton <paulburton@...nel.org>
> >> >> 
> >> >> The MIPS I6500 CPU & CM (Coherence Manager) 3.5 introduce the concept of
> >> >> multiple clusters to the system. In these systems each cluster contains
> >> >> its own GIC, so the GIC isn't truly global any longer. We do have the
> >> >> ability to access registers in the GICs of remote clusters using a
> >> >> redirect register block much like the redirect register blocks provided
> >> >> by the CM & CPC, and configured through the same GCR_REDIRECT register
> >> >> that we our mips_cm_lock_other() abstraction builds upon.
> >> >> 
> >> >> It is expected that external interrupts are connected identically to all
> >> >> clusters. That is, if we have a device providing an interrupt connected
> >> >> to GIC interrupt pin 0 then it should be connected to pin 0 of every GIC
> >> >> in the system. This simplifies things somewhat by allowing us for the
> >> >> most part to treat the GIC as though it is still truly global, so long
> >> >> as we take care to configure interrupts in the cluster that we want them
> >> >> affine to.
> >> > I can see how this can work for level interrupts, but how does this
> >> > work for edge interrupts? Is there any guarantee that the interrupt
> >> > will be discarded if routed to a cluster where it isn't configured?
> >> It is supposed to mask the interrupt out on the GIC which belongs to the
> >> cluster that the interrupt is not routed to.
> >> 
> >> When it's masked out GIC simply won't sense any level change.
> >> 
> >> I guess it's sort of guarantee?
> >
> > Pretty much the opposite. There is a *strong* requirement that a
> > masked interrupt can still detect interrupts, so that on unmask the
> > interrupt fires (you'd otherwise lose edge interrupts pretty often).
> Oops, sorry there is a terminology issue. On MIPS Coherent Manager
> manual it uses terminology of “Masked” when vector register of
> a interrupt is cleared.
> 
> It means implementation will guarantee interrupt will be dropped
> when it’s routed to nowhere.

Ah, right, that makes more sense.

Thanks,

	M.

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