Re: [PATCH v2] e1000e: Prevent crash from legacy interrupt firing after MSI-X enable

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]

On Mon, Aug 18, 2025 at 10:08:18AM +0800, Jason Wang wrote:
> On Thu, Aug 7, 2025 at 7:08 PM Laurent Vivier <lvivier@redhat.com> 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 <odaki@rsg.ci.i.u-tokyo.ac.jp>
> > Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> > ---
> 
> Acked-by: Jason Wang <jasowang@redhat.com>
> 
> 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.

Thanks!

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]