Something changed between kernel 5.16.0-rc3 and -rc4, and remains unfixed between -rc4 and -rc5. Attempting to start a QEMU VM, the display is stuck at "Guest has not initialized the display (yet)". The QEMU version I'm trying is 6.2.0-rc4, but QEMU version 6.1.0 has also been tried. I noticed many changes in the KVM code between Linux 5.16.0-rc3 and 5.16.0-rc4, and I apologize for not being able to narrow it down.
Created attachment 300019 [details]
qemu-kvm stack trace kernel 5.16.0-rc5
Qemu-kvm bug when starting VM with kernel 5.16.0-rc5.
Hi, this is your Linux kernel regression tracker speaking.
[TLDR: adding this regression to regzbot; most of this mail is compiled
from a few templates paragraphs some of you might have seen already.]
On 13.12.21 02:38, email@example.com wrote:
> Something changed between kernel 5.16.0-rc3 and -rc4, and remains unfixed
> between -rc4 and -rc5. Attempting to start a QEMU VM, the display is stuck at
> "Guest has not initialized the display (yet)". The QEMU version I'm trying is
> 6.2.0-rc4, but QEMU version 6.1.0 has also been tried. I noticed many changes
> in the KVM code between Linux 5.16.0-rc3 and 5.16.0-rc4, and I apologize for
> not being able to narrow it down.
Thanks for the report.
Adding the regression mailing list to the list of recipients, as it
should be in the loop for all regressions, as explained here:
To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:
#regzbot ^introduced v5.16-rc3..v5.16-rc4
#regzbot title Unable to launch QEMU Linux guest VM - "Guest has not
initialized the display (yet)"
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215317
Reminder: when fixing the issue, please add a 'Link:' tag with the URL
to the report (the parent of this mail), then regzbot will automatically
mark the regression as resolved once the fix lands in the appropriate
tree. For more details about regzbot see footer.
Sending this to everyone that got the initial report, to make all aware
of the tracking. I also hope that messages like this motivate people to
directly get at least the regression mailing list and ideally even
regzbot involved when dealing with regressions, as messages like this
wouldn't be needed then.
Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), as
long as they are intended just for regzbot. With a bit of luck no such
messages will be needed anyway.
Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat).
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave thus might sent someone reading this down the wrong
rabbit hole, which none of us wants.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
This is my goof. We're bikeshedding over a minor detail, but the fix should definitely be in rc6.
(In reply to Sean Christopherson from comment #3)
> This is my goof. We're bikeshedding over a minor detail, but the fix should
> definitely be in rc6.
Thx, the fix landed now:
#regzbot fixed-by: 18c841e1f4112d3fb742aca3429e84117fcb1e1c
Perfect! Thanks to all!