On Mon, Aug 18, 2025 at 10:03 PM Stefan Hajnoczi <stefa...@redhat.com> 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 <lviv...@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 <od...@rsg.ci.i.u-tokyo.ac.jp> > > > Signed-off-by: Laurent Vivier <lviv...@redhat.com> > > > --- > > > > Acked-by: Jason Wang <jasow...@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.
I see, I think it's not a release blocker so we can defer this to the next release. Thanks > > Thanks! > > Stefan
