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, 07 Jul 2022 17:12:42 +0200
From:   Sander Vanheule <sander@...nheule.net>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc:     Marc Zyngier <maz@...nel.org>,
        Aleksander Jan Bajkowski <olek2@...pl>,
        Hauke Mehrtens <hauke@...ke-m.de>, git@...ger-koblitz.de,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: smp-mt: enable all hardware interrupts on second
 VPE

On Thu, 2022-07-07 at 16:39 +0200, Thomas Bogendoerfer wrote:
> On Thu, Jul 07, 2022 at 02:57:15PM +0200, Martin Blumenstingl wrote:
> > On Thu, Jul 7, 2022 at 12:11 PM Thomas Bogendoerfer
> > <tsbogend@...ha.franken.de> wrote:
> > [...]
> > > > - why can MIPS CPU interrupt 6 and 7 be enabled unconditionally while
> > > > 2-5 cannot be enabled unconditionally?
> > > 
> > > 7 is timer interrupt and is usually wired for 34K cpus and 6 is
> > > performance counter hopefully handled as well. And I agree that
> > > this still isn't the best approach here
> > Thanks for this explanation!
> > 
> > > > - seeing that there's also a mips_gic_present() check in the opposite
> > > > case of what Aleksander's patch modifies: does this indicate that
> > > > unmasking CPU interrupt lines for VPE 1 is not handled by the MIPS CPU
> > > > interrupt controller driver at all at this point (and if so: do you
> > > > have any suggestions how to properly fix this)?
> > > 
> > > I haven't checked how GIC is integrated. Iirc it does something similair
> > > to Lantiq's irq controller and hides all CPU internal interrupts behind
> > > it.
> > > 
> > > So I see two solutions for your problem.
> > > 
> > > 1. Add "mti,cpu-interrupt-controller" to the DT and wire it up
> > I think this is the preferred way. I tried this before (if you are
> > curious, see [0] and [1]) and it didn't work.
> > Are you aware of any MIPS SoC with upstream drivers which do have
> > working IRQs on VPE 1?
> 
> I don't know of such SoC. Looking at the comment in vsmp_init_secondary()
> 
> /* This is Malta specific: IPI,performance and timer interrupts */
> 
> there is probably some Malta board using it.
> 
> > Or can you point me to the code in
> > drivers/irqchip/irq-mips-cpu.c that's responsible for enabling the
> > interrupts on VPE 1 (is it simply unmask_mips_irq)?
> 
> IMHO there is the problem, irq-mips-cpu.c can only do CPU irq operations
> on the same CPU. I've checked MIPS MT specs and it's possible do
> modify CP0 registers between VPEs. Using that needs changes in
> irq-mips-cpu.c. But mabye that's not woth the effort as probably
> all SMP cabable platforms have some multi processort capable
> interrupt controller implemented.

Maybe I'm not getting this right, but as I understand vsmp_init_secondary() is
run on VPE1, changing the local c0_status on that VPE. When unmask_mips_irq() is
called from code running on VPE1, I would expect it does the same thing: enable
the requested irq on VPE1 by modifying the local c0_status register.

Since these IRQs can be configured VPE, aren't these then also per-cpu
interrupts? I have been wondering if a cascaded IRQ controller needs to take
special care with such per-cpu interrupts, but haven't been able to figure that
out until now.

Sorry if the above doesn't make much sense, but like Aleksander I've been
struggling with this and would like to understand what the proper solution is.

Best,
Sander

> I thought about another way solve the issue. By introducing a
> new function in smp-mt.c which sets the value of the interrupt
> mask for the secondary CPU, which is then used in vsmp_init_secondary().
> Not sure if this is worth the effort compared to a .boot_secondary
> override.
> 
> Thomas.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ