[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: completion timeouts with pin-based interrupts in QEMU hw/nvme
From: |
Klaus Jensen |
Subject: |
Re: completion timeouts with pin-based interrupts in QEMU hw/nvme |
Date: |
Thu, 19 Jan 2023 09:02:15 +0100 |
On Jan 19 08:28, Klaus Jensen wrote:
> On Jan 18 21:03, Keith Busch 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 <kbusch@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.
> >
> > Also, we ought to revisit the intms/intmc usage in the linux driver for
> > threaded interrupts.
>
> +CC: qemu-riscv
>
> Keith,
>
> Thanks for digging into this!
>
> Yeah, you are probably right that we should only use the intms/intmc
> changes in the use_threaded_interrupts case, not in general. While my
> RFC patch does seem to "fix" this, it is just a workaround as your
> analysis indicate.
+CC: Philippe,
I am observing these timeouts/aborts on mips as well, so I guess that
emulation could suffer from the same issue?
signature.asc
Description: PGP signature