Windows guest hangs after reboot from the guest OS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qemu (Fedora) |
Unknown
|
Unknown
|
|||
qemu (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
In Progress
|
Undecided
|
Sergio Durigan Junior |
Bug Description
[ Impact ]
Some versions of Windows hang on reboot if their TSC value is greater
than 2^54. The calibration of the Hyper-V reference time overflows
and fails; as a result the processors' clock sources are out of sync.
[ Test Plan ]
As suggested by Mauricio, testing will be done in stages.
1) unit test, with such rdtsc/print loop (and confirm the tsc value decreases after system_reset).
This can be done by using x86/tsc.flat from the following repository:
https:/
Follow the steps below:
Inside a Jammy system (privileged container/VM, bare metal, etc.):
# apt update && apt install gcc make -y
# git clone https:/
# cd kvm-unit-tests
# wget https:/
# ./configure && make
Make sure x86/tsc exists. Now you can install qemu and perform the test:
# apt install -y qemu-system-x86
# qemu-system-x86_64 -serial file:/tmp/
Wait a couple of seconds and issue a "system_reset" command. Then, wait a couple more seconds and issue a "quit" command.
You can now open /tmp/bogus-output and check the values of rdtsc. You will notice that its value increments after the "system_reset", which is exactly what we don't want.
Afterwards, you can update qemu and test the fix by doing the same steps (make sure you adjust the "file:/tmp/..." path).
2) regression test, booting Ubuntu kernel/initrd pairs (installer's should be enough) from supported releases, and checking they boot/reach a prompt.
[ Where problems could occur ]
This is a change impacting normal x86 code, so although the patch is small and well contained, in the unlikely case that we find a regression it will impact more users. As such, and under Mauricio's advice, the test plan is being extended to really guarantee that the common virtualization scenarios are not impacted. If we find a problem with this update, there is the possibility of reverting it temporarily until we can devise a proper fix.
[ Original Description ]
Description:
Some versions of Windows hang on reboot if their TSC value is greater
than 2^54. The calibration of the Hyper-V reference time overflows
and fails; as a result the processors' clock sources are out of sync.
The issue is that the TSC _should_ be reset to 0 on CPU reset and
QEMU tries to do that. However, KVM special cases writing 0 to the
TSC and thinks that QEMU is trying to hot-plug a CPU, which is
correct the first time through but not later. Thwart this valiant
effort and reset the TSC to 1 instead, but only if the CPU has been
run once.
For this to work, env->tsc has to be moved to the part of CPUArchState
that is not zeroed at the beginning of x86_cpu_reset.
Solution: [PATCH] target/i386: properly reset TSC on reset
I created and tested a ppa ubuntu package already. The patch fixes this issue.
Link to ppa: https:/
It affects only jammy 22.04 package. The newest version is: qemu-1:
Related branches
- git-ubuntu bot: Approve
- Bryce Harrington (community): Approve
- Canonical Server Reporter: Pending requested
-
Diff: 104 lines (+82/-0)3 files modifieddebian/changelog (+7/-0)
debian/patches/series (+1/-0)
debian/patches/ubuntu/lp-2064914-properly-reset-tsc-on-reset.patch (+74/-0)
description: | updated |
Changed in qemu (Ubuntu Jammy): | |
status: | New → Triaged |
Changed in qemu (Ubuntu): | |
status: | New → Incomplete |
description: | updated |
description: | updated |
Changed in qemu (Ubuntu Jammy): | |
status: | Incomplete → In Progress |
Changed in qemu (Ubuntu): | |
status: | Incomplete → Invalid |
status: | Invalid → Fix Released |
description: | updated |
The attachment "Patch imported from RHEL 8" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]