Merge ~sergiodj/ubuntu/+source/qemu:lp2064914-windows-hangs-tsc-jammy into ubuntu/+source/qemu:ubuntu/jammy-devel

[Sergio Durigan Junior]

This MP fixes bug #2064914.

The bug affects Windows, so I am relying on the reporter to verify the fix. Meanwhile, I'm building the package here:

PPA: https://launchpad.net/~sergiodj/+archive/ubuntu/qemu

I'll run dep8 tests and the regular migration test soon.

[Sergio Durigan Junior (sergiodj)]

dep8 tests are going to take a long time to run. I will upload the package anyway and check the test results after the SRU has been accepted.

[Sergio Durigan Junior (sergiodj)]

Package uploaded.

[Bryce Harrington (bryce)]

Autopkgtests vs. the PPA look ok:
  - qemu/1:6.2+dfsg-2ubuntu6.20~ppa1
    + ✅ qemu on jammy for amd64 @ 17.05.24 16:21:04 Log️ 🗒️
    + ✅ qemu on jammy for arm64 @ 12.05.24 22:39:07 Log️ 🗒️
    + ✅ qemu on jammy for armhf @ 10.05.24 02:46:05 Log️ 🗒️
    + ✅ qemu on jammy for ppc64el @ 15.05.24 20:22:17 Log️ 🗒️
    + ✅ qemu on jammy for s390x @ 14.05.24 16:41:06 Log️ 🗒️

The patch itself looks ok. Could there be any ABI concerns for tsc moving around in the struct? I'm assuming since qemu is not a library it isn't.

The SRU template needs filling out, but that's known already.

mfo has some review suggestions on the bug report worth considering prior to uploading.

review: Approve

[git-ubuntu bot (git-ubuntu-bot)]

Approvers: sergiodj, bryce
Uploaders: sergiodj, bryce
MP auto-approved

review: Approve

diff --git a/debian/changelog b/debian/changelog
index ab23ca0..41ab654 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qemu (1:6.2+dfsg-2ubuntu6.20) jammy; urgency=medium
+
+  * d/p/u/lp-2064914-properly-reset-tsc-on-reset.patch: Properly reset
+    TSC on reset, fixing Windows hang after reboot. (LP: #2064914).
+
+ -- Sergio Durigan Junior <[e-mail]>  Thu, 09 May 2024 14:30:38 -0400
+
 qemu (1:6.2+dfsg-2ubuntu6.19) jammy; urgency=medium
 
   * d/p/u/lp2012763-maxcpus-too-low.patch: Bump max_cpus to 1024 on
diff --git a/debian/patches/series b/debian/patches/series
index ba7a4ad..732e144 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -124,3 +124,4 @@ CVE-2021-3611-24.patch
 ubuntu/lp-2046439-target-s390x-Split-out-gen_ri2.patch
 ubuntu/lp-2046439-s390x-Fix-emulation-of-C-G-HRL.patch
 ubuntu/lp2012763-maxcpus-too-low.patch
+ubuntu/lp-2064914-properly-reset-tsc-on-reset.patch
diff --git a/debian/patches/ubuntu/lp-2064914-properly-reset-tsc-on-reset.patch b/debian/patches/ubuntu/lp-2064914-properly-reset-tsc-on-reset.patch
 new file mode 100644
index 0000000..ebfbb0a
--- /dev/null
+++ b/debian/patches/ubuntu/lp-2064914-properly-reset-tsc-on-reset.patch
@@ -0,0 +1,74 @@
+From: Paolo Bonzini <[e-mail]>
+Date: Thu, 24 Mar 2022 09:21:41 +0100
+Subject: target/i386: properly reset TSC on reset
+
+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.
+
+Reported-by: Vadim Rozenfeld <[e-mail]>
+Supersedes: <[e-mail]>
+Signed-off-by: Paolo Bonzini <[e-mail]>
+
+Origin: upstream, https://gitlab.com/qemu-project/qemu/commit/5286c3662294119dc2dd1e9296757337211451f6
+Bug-RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=1975840
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2064914
+---
+ target/i386/cpu.c | 13 +++++++++++++
+ target/i386/cpu.h |  2 +-
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/target/i386/cpu.c b/target/i386/cpu.c
+index aa9e636..3f08e90 100644
+--- a/target/i386/cpu.c
++++ b/target/i386/cpu.c
+@@ -5863,6 +5863,19 @@ static void x86_cpu_reset(DeviceState *dev)
+     env->xstate_bv = 0;
+ 
+     env->pat = 0x0007040600070406ULL;
++
++    if (kvm_enabled()) {
++        /*
++         * KVM handles TSC = 0 specially and thinks we are hot-plugging
++         * a new CPU, use 1 instead to force a reset.
++         */
++        if (env->tsc != 0) {
++            env->tsc = 1;
++        }
++    } else {
++        env->tsc = 0;
++    }
++
+     env->msr_ia32_misc_enable = MSR_IA32_MISC_ENABLE_DEFAULT;
+     if (env->features[FEAT_1_ECX] & CPUID_EXT_MONITOR) {
+         env->msr_ia32_misc_enable |= MSR_IA32_MISC_ENABLE_MWAIT;
+diff --git a/target/i386/cpu.h b/target/i386/cpu.h
+index 04f2b79..c6a6c87 100644
+--- a/target/i386/cpu.h
++++ b/target/i386/cpu.h
+@@ -1510,7 +1510,6 @@ typedef struct CPUX86State {
+     target_ulong kernelgsbase;
+ #endif
+ 
+-    uint64_t tsc;
+     uint64_t tsc_adjust;
+     uint64_t tsc_deadline;
+     uint64_t tsc_aux;
+@@ -1660,6 +1659,7 @@ typedef struct CPUX86State {
+     int64_t tsc_khz;
+     int64_t user_tsc_khz; /* for sanity check only */
+     uint64_t apic_bus_freq;
++    uint64_t tsc;
+ #if defined(CONFIG_KVM) || defined(CONFIG_HVF)
+     void *xsave_buf;
+     uint32_t xsave_buf_len;