linux-kernel - Re: [PATCH V2 18/24] irqchip: mips-gic: Stop using per-platform mapping tables

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] [day] [month] [year] [list]

Message-ID: <54B7F7F2.5010202@imgtec.com>
Date:	Thu, 15 Jan 2015 17:25:06 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Andrew Bresticker <abrestic@...omium.org>,
	Qais Yousef <qais.yousef@...tec.com>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Jeffrey Deans <jeffrey.deans@...tec.com>,
	Markos Chandras <markos.chandras@...tec.com>,
	Paul Burton <paul.burton@...tec.com>,
	Jonas Gorski <jogo@...nwrt.org>,
	"John Crispin" <blogic@...nwrt.org>,
	David Daney <ddaney.cavm@...il.com>,
	Linux-MIPS <linux-mips@...ux-mips.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 18/24] irqchip: mips-gic: Stop using per-platform mapping
 tables

On 15/01/15 16:58, Andrew Bresticker wrote:
> Hi James, Qais,
> 
> On Thu, Jan 15, 2015 at 8:36 AM, Qais Yousef <qais.yousef@...tec.com> wrote:
>> On 01/15/2015 04:29 PM, James Hogan wrote:
>>>
>>> On 15/01/15 11:59, James Hogan wrote:
>>>>
>>>> Hi Andrew,
>>>>
>>>> On 18/09/14 22:47, Andrew Bresticker wrote:
>>>>>
>>>>> Now that the GIC properly uses IRQ domains, kill off the per-platform
>>>>> routing tables that were used to make the GIC appear transparent.
>>>>>
>>>>> This includes:
>>>>>   - removing the mapping tables and the support for applying them,
>>>>>   - moving GIC IPI support to the GIC driver,
>>>>>   - properly routing the i8259 through the GIC on Malta, and
>>>>>   - updating IRQ assignments on SEAD-3 when the GIC is present.
>>>>>
>>>>> Platforms no longer will pass an interrupt mapping table to gic_init.
>>>>> Instead, they will pass the CPU interrupt vector (2 - 7) that they
>>>>> expect the GIC to route interrupts to.  Note that in EIC mode this
>>>>> value is ignored and all GIC interrupts are routed to EIC vector 1.
>>>>>
>>>>> Signed-off-by: Andrew Bresticker <abrestic@...omium.org>
>>>>> Acked-by: Jason Cooper <jason@...edaemon.net>
>>>>> Reviewed-by: Qais Yousef <qais.yousef@...tec.com>
>>>>> Tested-by: Qais Yousef <qais.yousef@...tec.com>
>>>>
>>>> This commit (18743d2781d01d34d132f952a2e16353ccb4c3de) appears to break
>>>> boot of interAptiv, dual core, dual vpe per core, on malta with
>>>> malta_defconfig.
>>>>
>>>> It gets to here:
>>>> ...
>>>> CPU1 revision is: 0001a120 (MIPS interAptiv (multi))
>>>> FPU revision is: 0173a000
>>>> Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
>>>> Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
>>>> MIPS secondary cache 1024kB, 8-way, linesize 32 bytes.
>>>> Synchronize counters for CPU 1: done.
>>>> Brought up 2 CPUs
>>>>
>>>> and then appears to just hang. Passing nosmp works around it, allowing
>>>> it to get to userland.
>>>>
>>>> Is that a problem you've already come across?
>>>>
>>>> I'll keep debugging.
>>>
>>> Right, it appears the CPU IRQ line that the GIC is using doesn't get
>>> unmasked (STATUSF_IP2) when a new VPE is brought up, so only the first
>>> CPU will actually get any interrupts after your patch (including the
>>> rather critical IPIs), i.e. hacking it in vsmp_init_secondary() in
>>> smp-mt.c allows it to boot.
>>>
>>> Hmm, I'll have a think about what the most generic fix is, since
>>> arbitrary stuff may or may not have registered handlers for the raw CPU
>>> interrupts (timer, performance counter, gic etc)...
>>>
>>> Cheers
>>> James
>>>
>>
>> Is this similar to the issue addressed by this (ff1e29ade4c6 MIPS: smp-cps:
>> Enable all hardware interrupts on secondary CPUs)?
> 
> I believe so.
> 
> James, I think you can apply a similar patch to smp-mt.c:vsmp_init_secondary.

Yes, I've come to the same conclusion. smp-cmp.c is also affected. I'll
post patches tomorrow.

Thanks
James


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)