kern/60297: virtio(4) polling is not properly supported for MMIO

["isaki%pastel-flower.jp@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60297
>Category:       kern
>Synopsis:       virtio(4) polling is not properly supported for MMIO
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 28 04:05:01 +0000 2026
>Originator:     Tetsuya Isaki
>Release:        NetBSD-current 20260520
>Organization:
>Environment:
NetBSD 11.99.6 virt68k
>Description:
Current virtio(4) implementation does not perform interrupt
acknowledge when polling in MMIO.

In VirtIO specification
( https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html ),
for PCI, the interrupt signal is automatically de-asserted when
the ISR is read.  However, for MMIO, the interrupt signal must be
de-asserted manually after reading the ISR.

| 4.1 Virtio Over PCI Bus
...
| 4.1.4.5 ISR status capability
...
| To avoid an extra access, simply reading this register resets it to 0
| and causes the device to de-assert the interrupt.
| In this way, driver read of ISR status causes the device to de-assert
| an interrupt. 

| 4.2 Virtio Over MMIO
...
| 4.2.3.4.1 Driver Requirements: Notifications From The Device
...
| After the interrupt is handled, the driver MUST acknowledge it by
| writing a bit mask corresponding to the handled events to the
| InterruptACK register


In MMIO mode, this interrupt acknowledge is properly performed by the
interrupt handler, virtio_mmio_intr (sys/dev/virtio/virtio_mmio.c).
However, this is not performed in the polling.

This is cause of spurious interrupt on virt68k that uses MMIO.

1. ld_virtio_attach issues a VirtIO command and waits by polling.
2. When the command completes, the interrupt status is asserted (but
   system interrupts are disabled at this point).
3. the virtio driver dequeues the result.
4. Once device enumeration finished, the kernel enables the system
   interrupts.
5. Then, virtio interrupt is immediately raised (because
   the interrupt is still asserted).
6. virtio interrupt handler then checks the virtio queue but the queue
   is empty (because already dequeued at step 3).  So the interrupt
   handler returns 0 (= not handled).

>How-To-Repeat:
Boot NetBSD/virt68k-current with ld@virtio.
Even QEMU can reproduce it.
>Fix:
N/A