This series fixes three cases where an NVMe legacy INTx interrupt may
remain asserted, causing an interrupt storm in the guest:
* cq_pending can underflow when a doorbell notification is processed for
a completion queue that is already empty.
* A stale CQ event index can cause the guest to suppress a subsequent
MMIO CQ doorbell write, preventing QEMU from observing the updated CQ
head.
* Controller reset does not clear pending CQ interrupt state.
Without these fixes, a Linux guest using legacy PCI interrupts may see
the following:
[ 2.058360] irq 23: nobody cared (try booting with the "irqpoll" option)
[ 2.058724] handlers:
[ 2.058820] [<000000006a09281a>] nvme_irq
[ 2.058966] [<000000006a09281a>] nvme_irq
[ 2.059113] Disabling IRQ #23
I reproduced the interrupt storm with Linux 6.12, 6.18, and 7.2 by
booting the guest with pci=nomsi. The cq_pending underflow occurred with
ioeventfd=on, but its fix covers both ioeventfd=on and ioeventfd=off
configurations. The stale event-index issue occurred with both
ioeventfd=on and ioeventfd=off.
The following command was used to reproduce the interrupt storm with
ioeventfd=on:
qemu-system-x86_64 \
-machine q35,accel=kvm \
-m 2G -smp 2 \
-kernel ./linux-7.2/arch/x86/boot/bzImage \
-append 'console=ttyS0 root=/dev/nvme0n1p1 rw pci=nomsi' \
-drive if=none,file=./guest-image.qcow2,id=disk0,format=qcow2 \
-device nvme,drive=disk0,serial=testserial0,ioeventfd=on \
-nographic
The controller-reset fix addresses QEMU issue 4142:
https://gitlab.com/qemu-project/qemu/-/work_items/4142
I was unable to reproduce this issue with a Linux guest, but a
controller reset must clear the CQ interrupt state and deassert the
interrupt line.
Kind regards,
Markku Ahvenjärvi
---
Markku Ahvenjärvi (3):
hw/nvme: prevent cq_pending underflow
hw/nvme: fix missed CQ updates
hw/nvme: clear interrupts on controller reset
hw/nvme/ctrl.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
---
base-commit: 7074591d7954876951f84c15b994a43251d5a3c1
change-id: 20260922-nvme-intx-fixes-10b70b6520ba
Best regards,
--
Markku Ahvenjärvi <mankku@gmail.com>