linux-kernel - Re: [PATCH] MIPS: smp-mt: enable all hardware interrupts on second VPE

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]

Message-ID: <CAFBinCAsj=RNvitj2tXJU6pTLSbanRXdKM9H4vyF=N9N=PP06g@mail.gmail.com>
Date:   Wed, 6 Jul 2022 11:56:47 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc:     Marc Zyngier <maz@...nel.org>,
        Sander Vanheule <sander@...nheule.net>,
        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

Hi Thomas,

On Wed, Jul 6, 2022 at 11:42 AM Thomas Bogendoerfer
<tsbogend@...ha.franken.de> wrote:
[...]
> > But this is only enabling interrupts at the CPU level, right? And the
> > irqchip is still in control of the masking of the individual
> > interrupts?
>
> in the Lantiq case yes
>
> > If both assertions are true, then this patch seems OK. If it just let
> > any interrupt through without any control, then this is wrong.
> >
> > So which one is it?
>
> if there isn't an additional irqchip connected to the cpu interrupt lines,
> this patch will cause problems.
on Lantiq xRX200 SoCs (34Kc with two VPEs) we basically have:
  cpu_irqc: interrupt-controller {
      compatible = "mti,cpu-interrupt-controller";

      interrupt-controller;
      #interrupt-cells = <1>;
  };

  &icu {
      compatible = "lantiq,icu";

      interrupt-parent = <&cpu_irqc>;
      interrupts = <2>, <3>, <4>, <5>, <6>;

      interrupt-controller;
      #interrupt-cells = <1>;
  }
meaning: the Lantiq ICU interrupt controller provides 5*32 interrupt
lines through 5 MIPS CPU interrupt lines

Without this patch all interrupts are fine on VPE 0 and with SMP disabled.
The ICU interrupt controller can route interrupts either to VPE 0 or VPE 1.
Routing to VPE 1 is the problem: only the upper-most 32 interrupt
lines (connected to MIPS CPU interrupt line 6) are working, all other
interrupts never arrive on VPE 1. This is because MIPS CPU interrupt
line is enabled, even before Aleksander's patch.

With Aleksander's patch all 5*32 interrupts (at least all the ones I
have tested) can be routed to VPE 1 as well.
I understand that this doesn't mean that Aleksander's patch is
automatically correct. My two main questions are:
- why can MIPS CPU interrupt 6 and 7 be enabled unconditionally while
2-5 cannot be enabled unconditionally?
- 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)?


Best regards,
Martin