Hi Jason,
On 19/08/2025 04:46, Jason Wang wrote:
On Mon, Aug 18, 2025 at 10:03 PM Stefan Hajnoczi <[email protected]> wrote:
On Mon, Aug 18, 2025 at 10:08:18AM +0800, Jason Wang wrote:
On Thu, Aug 7, 2025 at 7:08 PM Laurent Vivier <[email protected]> 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().
This patch removes the assertion and executes the code that clears the
pending legacy causes. This change is safe and introduces no unintended
behavioral side effects, as it only alters a state that previously led
to termination.
- when core->delayed_causes == 0 the function was already a no-op and
remains so.
- when core->delayed_causes != 0 the function would previously
crash due to the assertion failure. The patch now defines a safe
outcome by clearing the cause and returning. Since behavior after
the assertion never existed, this simply corrects the crash.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1863
Suggested-by: Akihiko Odaki <[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>
---
Acked-by: Jason Wang <[email protected]>
Consider rc3 is out. Can this be applied directly by maintainers or a
PULL request is expected?
The commit description doesn't mention whether this fixes a regression
introduced since QEMU 10.0, whether there is a security impact, etc.
In the absence of more information, this looks like a regular bug fix
that does not need to be merged for -rc4.
Only release blockers will be merged for -rc4 (Tue 19 Aug). Please
provide a justification if this commit is a release blocker. Reasoning:
- From -rc3 onwards the goal is to make the final release and adding
additional patches risks introducing new issues that will delay the
release further.
- Commits should include enough information to make the decision to
merge easy and documented in git-log(1). Don't rely on me to judge the
severity in areas of the codebase I'm not an expert in.
I see, I think it's not a release blocker so we can defer this to the
next release.
just a reminder not to forget to pull it now...
Thanks,
Laurent
