On Thu, 19 Jan 2023 at 04:03, Keith Busch <kbu...@kernel.org> wrote: > > On Thu, Jan 19, 2023 at 01:10:57PM +1000, Alistair Francis wrote: > > On Thu, Jan 19, 2023 at 12:44 PM Keith Busch <kbu...@kernel.org> wrote: > > > > > > Further up, it says the "interrupt gateway" is responsible for > > > forwarding new interrupt requests while the level remains asserted, but > > > it doesn't look like anything is handling that, which essentially turns > > > this into an edge interrupt. Am I missing something, or is this really > > > not being handled? > > > > Yeah, that wouldn't be handled. In QEMU the PLIC relies on QEMUs > > internal GPIO lines to trigger an interrupt. So with the current setup > > we only support edge triggered interrupts. > > Thanks for confirming! > > Klaus, > I think we can justify introducing a work-around in the emulated device > now. My previous proposal with pci_irq_pulse() is no good since it does > assert+deassert, but it needs to be the other way around, so please > don't considert that one.
No, please don't. The bug is in the risc-v interrupt controller, so fix the risc-v interrupt controller. It shouldn't be too difficult (you probably have to do something like what the Arm GIC implementation does, where when the guest dismisses the interrupt you look at the level to see if it needs to be re-pended.) Once "workarounds" go into QEMU device emulation that make it deviate from hardware behaviour, it's hard to get rid of them again, because nobody knows whether deployed guests now accidentally rely on the wrong behaviour. So the correct thing is to never put in the workaround in the first place. thanks -- PMM