linux-kernel - Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver

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, 2 Aug 2018 11:35:43 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Christoph Hellwig <hch@....de>
cc:     Marc Zyngier <marc.zyngier@....com>, palmer@...ive.com,
        jason@...edaemon.net, robh+dt@...nel.org, mark.rutland@....com,
        devicetree@...r.kernel.org, aou@...s.berkeley.edu,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        shorne@...il.com, Palmer Dabbelt <palmer@...belt.com>
Subject: Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver

On Thu, 2 Aug 2018, Christoph Hellwig wrote:
> The cpu local interrupt handling, which was irq-riscv-intc.c in this
> series and has been moved to arch/riscv/kernel/irq.c in my new series
> is split over a few control registers (CSRs in RISC-V speak):
> 
> The exception handler, which includes the delivery of interrupts to
> the CPU is set up using the stvec CSR (Section 4.1.4).  The vector mode
> mentioned there is not supported by Linux (and not by any hardware known
> to me), so ignore it.

And even if it would be available then it would just avoid the software
decoding of the cause register. So no fundamental difference.

> Once an exception has been triggered Linux reads the scause CSR
> (Section 4.1.10) to check the exception cause.  If the interrupt
> bit is set we have three possible exception causes that matter for
> the kernel: Supervisor software interrupt, Supervisor timer interrupt,
> Supervisor external interrupt (ignore the user versions, I'm not even
> sure they are implementable, and they certainly are not at the moment).

Yeah. I would upfront declare the user stuff broken and not supported.

> To enable / disable any of these logical interrupt sources the sie
> CSR (Section 4.1.5) has a bit for each kind thast can be set/cleared.
> 
> Also there is the sip CSR (also section 4.1.5) which tells if any of those
> is pending at the moment.

So that's the low level per cpu interrupt/exception distribution mechanism,
i.e. a distinct per cpu 'vector' space with fixed functionality. It does
not make sense to actually handle that as an irq chip. It has absolutely no
relevance. The software interrupts are enabled when the CPU is started and
the external ones as well as they are gated by the PLIC.

The only thing which might need to access the enable register is the local
timer interrupt. That really does not require an extra irq chip as the
enable/disable is really just at cpu up/down time and the magic happens on
the local CPU so no smp functional call hackery is required.

The PLIC is the beast which wants a proper irqdomain/irqchip
implementation.

Thanks,

	tglx