linux-kernel - Re: [PATCH 10/14] irqchip/mips-gic: Add a IPI hierarchy domain

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:	Tue, 17 Nov 2015 11:11:44 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Qais Yousef <qais.yousef@...tec.com>
cc:	linux-kernel@...r.kernel.org, jason@...edaemon.net,
	marc.zyngier@....com, jiang.liu@...ux.intel.com,
	ralf@...ux-mips.org, linux-mips@...ux-mips.org
Subject: Re: [PATCH 10/14] irqchip/mips-gic: Add a IPI hierarchy domain

On Tue, 17 Nov 2015, Qais Yousef wrote:
> On 11/16/2015 05:17 PM, Thomas Gleixner wrote:
> > On Mon, 9 Nov 2015, Qais Yousef wrote:
> > > On 11/07/2015 02:51 PM, Thomas Gleixner wrote:
> > > Generally it's hard to know whether a real device is connected to a hwirq
> > > or
> > > not. I am saving a patch where we get a set of free hwirqs from DT as only
> > > the
> > > SoC designer knows what hwirq are actually free and safe to use for IPI.
> > > I'll
> > > send this patch with the DT IPI changes or the rproc driver that I will be
> > > send once these changes are merged.
> > > 
> > > The current code assumes that the last 2 * NR_CPUs hwirqs are always free
> > > to
> > > use for Linux SMP.
> > So what you're saying is that you cannot rely on the last X hwirqs
> > being available for IPIs. That's insane and to my knowledge there is
> > no hardware out there which does not reserve a consecutive IPI space.
> 
> If I read the code you were suggesting correctly, you were trying to fit the
> IPIs in any available non allocated area in the GIC space. What I am trying to
> say is that we can only work on a limited subset of this space that we are
> told explicitly it's safe to use for IPIs. Most likely it's consecutive, but I
> don't feel brave enough to make this assumption personally - maybe I'm over
> paranoid.. I'm more keen on anything that would simplify this patch series now
> though.

Right, I was assuming a consecutive available space and your hardware
folks should really avoid to break that assumption.

Now you still need some DT support to describe the space which is
available for IPIs and that should be part of that series.

> I'll do my best with the next series but maybe we'd need to iterate
> this more than once till I get it right.

Thanks for being patient and persistant on that!

       tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/