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

Date:	Thu, 15 Jan 2015 16:29:26 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Andrew Bresticker <abrestic@...omium.org>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>
CC:	Jeffrey Deans <jeffrey.deans@...tec.com>,
	Markos Chandras <markos.chandras@...tec.com>,
	Paul Burton <paul.burton@...tec.com>,
	"Qais Yousef" <qais.yousef@...tec.com>,
	Jonas Gorski <jogo@...nwrt.org>,
	"John Crispin" <blogic@...nwrt.org>,
	David Daney <ddaney.cavm@...il.com>,
	<linux-mips@...ux-mips.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 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


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