linux-kernel - Re: [PATCH 09/15] irq: arm: perform irqentry in entry code

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: <87ilxnc21r.wl-maz@kernel.org>
Date:   Sat, 23 Oct 2021 14:18:24 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Vladimir Murzin <vladimir.murzin@....com>
Cc:     Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org,
        aou@...s.berkeley.edu, catalin.marinas@....com,
        deanbo422@...il.com, green.hu@...il.com, guoren@...nel.org,
        jonas@...thpole.se, kernelfans@...il.com,
        linux-arm-kernel@...ts.infradead.org, linux@...linux.org.uk,
        nickhu@...estech.com, palmer@...belt.com, paulmck@...nel.org,
        paul.walmsley@...ive.com, peterz@...radead.org, shorne@...il.com,
        stefan.kristiansson@...nalahti.fi, tglx@...utronix.de,
        torvalds@...ux-foundation.org, tsbogend@...ha.franken.de,
        vgupta@...nel.org, will@...nel.org
Subject: Re: [PATCH 09/15] irq: arm: perform irqentry in entry code

On Sat, 23 Oct 2021 13:06:25 +0100,
Vladimir Murzin <vladimir.murzin@....com> wrote:
> 
> On 10/22/21 7:43 PM, Marc Zyngier wrote:
> > On Fri, 22 Oct 2021 18:58:54 +0100,
> > Mark Rutland <mark.rutland@....com> wrote:
> >>
> >> On Fri, Oct 22, 2021 at 05:34:20PM +0100, Vladimir Murzin wrote:

[...]

> >>> As for TODO, is [1] look something you have been thinking of? IIUC,
> >>> the show stopper is that hwirq is being passed from exception entry
> >>> which retrieved via xPSR (IPSR to be precise). OTOH hwirq also available
> >>> via Interrupt Controller Status Register (ICSR) thus can be used in
> >>> driver itself... I gave [1] a go and it runs fine, yet I admit I might
> >>> be missing something...
> >>
> >> I hadn't thought about it in much detail, but that looks good!
> >>
> >> I was wondering if we needed something like a
> >> handle_arch_vectored_irq(), but if we can rely on the ICSR that seems
> >> simpler overall. I'm not at all familiar with M-class, so I'm not sure
> >> if there are pitfalls in this area.
> > 
> > Why can't we just use IPSR instead from the C code? It has the
> > potential of being of lower latency then a MMIO read (though I have no
> > idea whether it makes a material difference on M-class) and from what
> > I can see in the arch spec, they are strictly equivalent.
> 
> Hmmm, less arch specific asm(s) in driver code, no?

Well, it isn't like this driver is going to be useful on anything
else, is it?

If there is no overhead in reading from MMIO compared to the
architected register, then I agree that ICSR is the way to
go. Is there any chance you could measure it on a HW platform? Or
maybe in emulation?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.