On 06/08/2025 19.44, Akihiko Odaki wrote:
On 2025/08/07 0:29, Laurent Vivier wrote:
A race condition between guest driver actions and QEMU timers can lead
to an assertion failure when the guest switches the e1000e from legacy
interrupt mode to MSI-X. If a legacy interrupt delay timer (TIDV or
RDTR) is active, but the guest enables MSI-X before the timer fires,
the pending interrupt cause can trigger an assert in
`e1000e_intmgr_collect_delayed_causes()`.
The function's assertion (`assert(core->delayed_causes == 0)`)
incorrectly assumes that it's impossible for a legacy delayed interrupt
to be pending once the device is in MSI-X mode.
This behavior is incorrect. On a physical device, a driver-initiated
mode switch would mask interrupts, reconfigure the hardware, and clear
any stale interrupt states. The legacy delay timers (TIDV/RDTR) are not
used for moderation in MSI-X mode; the Interrupt Throttle Rate (ITR)
mechanism is used instead. Therefore, any pending interrupt from the
old mode should be ignored.
It is true that triggering assertion is incorrect as per: docs/devel/secure-
coding-practices.rst
However, I don't see statements in the datasheet that says mode switch will
clear stale interrupts.
The expression "TIDV/RDTR are not used for moderation in MSI-X mode" is also
unclear. Behaving drivers may indeed use ITR for that purpose, but the
question for us is: what will e1000e do when the guest tries to use TIDV/
RDTR in MSI-X mode anyway? That defines the behavior we need to implement.
If it's not clear what to do here, maybe we could use a
qemu_log_mask(LOG_UNIMP, ...) for now?
Thomas
