FS#72457 - [qemu] Windows 7 under latest qemu crashes when kvm is enabled

Attached to Project: Arch Linux
Opened by Chris Barry (a_aguecheek) - Sunday, 17 October 2021, 14:56 GMT
Last edited by David Runge (dvzrv) - Friday, 30 September 2022, 09:25 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
David Runge (dvzrv)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
After running pacman -Su after a lapse of several months I found that previously working Windows 7 virtual machines would halt with a blue screen and error 0xFE just after displaying "Starting Windows". The same error would occur when booting from a Windows 7 installation image. However, a rather old Clonezilla image seemed to boot without problems.

I was using my own build of kernel 5.7.2, which was not replaced during the update. Switching to the 4.14.12-arch1-1 did not help, nor did a fresh build of 4.14.12.

When "-enable-kvm" was removed from the command line then Windows ran normally but slowly.

I cloned the Qemu source and built the latest version, which failed in the same way, but when I built "version 5.2.95 (v6.0.0-rc5-dirty)" the Windows VMs (32 and 64 bit) seemed to run normally.

Additional info:
* package version(s): qemu 6.1.0-5
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:
/bin/qemu-system-x86_64 -enable-kvm -cdrom path.to.windows7.iso -m 2048
halts with a blue screen shortly after displaying "Starting Windows".
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 30 September 2022, 09:25 GMT
Reason for closing:  No response
Comment by Chris Barry (a_aguecheek) - Sunday, 17 October 2021, 15:00 GMT
Kernel versions should be 5.14.12, not 4.14.12.
Comment by agapito fernandez (agapito) - Tuesday, 19 October 2021, 18:55 GMT
Same behavior here: can't boot Win 7, Win 8 & Win 10 isos when -enable-kvm parameter is used.

Kernel is: 5.14.13-arch1-1. No relevant logs found.
Comment by Anatol Pomozov (anatolik) - Tuesday, 19 October 2021, 18:59 GMT
I vaguely remember there were several similar bug reports. And AFAIK it was related to changed ovmf firmware format.
Comment by David Runge (dvzrv) - Friday, 20 May 2022, 19:07 GMT
Is this still an issue with qemu >= 7.0.0?
Comment by Heorhii Valakhanovich (tormoz) - Friday, 20 May 2022, 19:13 GMT
have you tried -cpu host-model or at least -cpu qemu64 ?
I noticed that qemu uses -cpu kvm64 by default and it will not work with modern windows.
Comment by Chris Barry (a_aguecheek) - Monday, 06 June 2022, 22:44 GMT
I hadn't noticed that Qemu version 7 had been released, so I updated to the latest Arch version (of QEMU, everything else is still about 3 weeks out of date). It fails in exactly the same way as the previous version.

I decided to experiment with the -cpu option. (Incidentally, unless I am misunderstanding Qemu, qemu64 and kvm64 are equivalent.) I have an AMD E-450 CPU and I couldn't see anything especially relevant in the list but I tried various options and eventually found that "-cpu max" would work, although "-cpu base" gave the usual fault.

So far I have not tested it extensively, but I have tried it with a Windows 2016 system that I set up recently and that gets through the log in screen with "-cpu max" but fails well before that point with the default settings.

Incidentally, the Windows 2016 system gives the diagnostic message "Stop code: SYSTEM THREAD EXCEPTION NOT HANDLED" if this is of any use to anyone who is trying to fix the problem.

I used a Windows 7 installation ISO image for most of my tests, with a freshly created qcow2 image for the hard disk. I checked the time that each test took to get to the point where it says "Starting Windows" and, interestingly, Qemu version 7 seems to take substantially longer (170 seconds compared to 90 seconds) than the version 5.2.95 that I built six months ago, and this didn't alter much with cpu or even with accel=tcg. However, the time to get from "Starting Windows" to displaying the region selection screen was similar for both versions.
Comment by David Runge (dvzrv) - Wednesday, 17 August 2022, 08:51 GMT
> so I updated to the latest Arch version (of QEMU, everything else is still about 3 weeks out of date).

Partial upgrades are not supported. Please fully upgrade your system and try again.

As Anatol pointed out in https://bugs.archlinux.org/task/72457#comment203101 did you try to setup your edk2-ovmf based firmware stuff again? You might have to alter the configuration XML of the existing VM to point to the correct files.

Does this also happen with a completely new VM? From your report and comments it is not clear whether you have only tried on previously existing VMs or also attempted to create a new one.
Comment by Elkana (ttv20) - Wednesday, 17 August 2022, 17:43 GMT
I have similar problem
After upgrading to 5.17/5.18 all windows VM stop working
If I boot with LTS they work normally
I tried zen kernel too
I'm using virt-manager
You think it connected?
Comment by Elkana (ttv20) - Thursday, 01 September 2022, 06:06 GMT
Somewhere between Kernel 5.19.2 to 5.19.5 it solved for me

Loading...