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: <CAFBinCBq3ydoxtj1VG=kjqbq5NjP1ZnQe_dOAS2Gjm2fNkK9Yg@mail.gmail.com>
Date:   Thu, 28 Jul 2022 17:50:10 +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 Thu, Jul 7, 2022 at 4:40 PM Thomas Bogendoerfer
<tsbogend@...ha.franken.de> wrote:
[...]
> > 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.
On Lantiq the "multi processor capable interrupt controller" solution
seems not very sophisticated: there's simply two identical copies of
the IRQ controller IP, one connected to CPU0 and the other to CPU1.

> 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.
I think for the Realtek SoC's this would be problematic because it's
using MIPS_GENERIC. My understanding is that in an ideal world all
platforms would switch to MIPS_GENERIC.
As an alternative to making irq-mips-cpu capable of changing another
CPU's registers: would you also be happy with a change that implements
the following idea (pseudocode) in vsmp_init_secondary():
    struct device_node *root_node = of_find_node_by_path("/");

    if (mips_gic_present() ||
        of_device_is_compatible(root_node, "lantiq,xrx200") ||
        of_device_is_compatible(root_node, "realtek,some-relevant-soc"))
        change_c0_status(ST0_IM, STATUSF_IP2 | STATUSF_IP3 |
            STATUSF_IP4 | STATUSF_IP5 |
            STATUSF_IP6 | STATUSF_IP7);
    else
       ...

    of_node_put(root_node);

That way we don't risk enabling interrupt lines which shouldn't be
enabled (on SoCs which we don't know).
And also it would not cause any issues with MIPS_GENERIC support.


Best regards,
Martin