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
| ||
|
Date: Thu, 10 Nov 2022 01:27:24 +0530 From: Mukesh Ojha <quic_mojha@...cinc.com> To: Marc Zyngier <maz@...nel.org> CC: <linux-arm-kernel@...ts.infradead.org>, <catalin.marinas@....com>, <will@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, lkml <linux-kernel@...r.kernel.org> Subject: Re: Query on handling some special Group0 interrupt in Linux Hi Marc, Thanks for your reply. On 11/9/2022 11:50 PM, Marc Zyngier wrote: > On Wed, 09 Nov 2022 16:20:35 +0000, > Mukesh Ojha <quic_mojha@...cinc.com> wrote: >> >> Hi, >> >> I was working on a use case where both el2/el3 are implemented and we >> have a watchdog interrupt (SPI), which is used for detecting software >> hangs and cause device reset; If that interrupt's current cpu affinity >> is on a core, where interrupts are disabled, we won't be able to serve >> it or if this interrupt comes on a core which has interrupt enabled, >> calling panic() or with smp_send_stop(), we would not be able >> to know the call stack of the other cores which is running with >> interrupt disabled. >> >> I was thinking of configuring both a watchdog irq(SPI) and IPI_STOP >> (SGI) or any reserve IPI as an FIQ. And from the watchdog irq handler, >> I was thinking of calling panic() which eventually sends IPI_STOP(SGI >> FIQ) to all the cores. And with this we will able to dump all the core >> call stack. >> >> I am able to achieve this but wanted to know if this is acceptable to >> the community to support/allow such use cases like above and enable >> group0 interrupt from GIC for some special use cases. > > For a start, we only deal with Group-1 interrupts in Linux. Group-0 > interrupts are for the firmware, and we really don't want to see them > (this is consistent with your HW having EL3). What is the downside of it we support this ? I see one of the implementation here. https://elixir.bootlin.com/linux/v6.0.7/source/drivers/irqchip/irq-apple-aic.c#L510 >We also mask IRQ and FIQ at the same time, so this is a non-starter. This can be taken care if we support this. > > If you want to be able to deliver an interrupt while the interrupts > are masked, what you are looking for is the NMI framework, for which > you can register SPIs as (pseudo-)NMI. Yes, kind of NMI. I have already looked into this. Since, in our system El2 is implemented and each physical interrupt get routed to hypervisor and later vIrq comes to El1 and each interrupt enable/disable call exercise pmr register trap can cause latency in regular run(like multiple VM). Since, some of the use-case could be special like i have mentioned in my initial mail where such interrupt will be fatal and system will get reset after that. I am not able to think of any other use case than this but can this not be considered as one of the feature. > > This is of course assuming that you're using GICv3. If you're using an > older version of the architecture, we don't have a good solution for > you, unfortunately. > we are using GICv3. > Thanks, > > M. > -Mukesh
Powered by blists - more mailing lists