From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, Vadim Rozenfeld <vrozenfe@redhat.com>
Subject: Re: [PATCH] target/i386: introduce CPU property to work around Windows reset bug
Date: Thu, 24 Mar 2022 09:15:54 +0000 [thread overview]
Message-ID: <Yjw2yvN1OHkmBb2X@redhat.com> (raw)
In-Reply-To: <Yjw2KG4y8fK5Dw4F@redhat.com>
On Thu, Mar 24, 2022 at 09:13:12AM +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 24, 2022 at 09:23:46AM +0100, Paolo Bonzini wrote:
> > 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.
> > As a workaround, reset the TSC to a small value. Do not do this
> > unconditionally and require a special property to be set.
>
> What's the problem with doing it unconditionally ?
>
> Requiring this special niche property means that it'll have to be
> enabled by management apps. Most will never learn it exists, and
> of those that do, many will take years to get this enabled and
> into usage by users, and many won't even bother.
>
> IMHO, this is the kind of situation where we need the fix to be
> enabled by default, or we might as well not bother.
Sigh, hit send too soon. I see the property is actually turned
on in the defaults below, so effectively it will always be on
unconditionally as no one will bother to add support for turning
it off.
>
> >
> > Reported-by: Vadim Rozenfeld <vrozenfe@redhat.com>
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> > target/i386/cpu.c | 10 ++++++++++
> > target/i386/cpu.h | 3 +++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index ec3b50bf6e..9b29cea8c4 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -5931,6 +5931,15 @@ static void x86_cpu_reset(DeviceState *dev)
> > env->xstate_bv = 0;
> >
> > env->pat = 0x0007040600070406ULL;
> > +
> > + /*
> > + * Some versions of Windows hang on reboot if their TSC value is greater
> > + * than 2^54. As a workaround, reset the TSC to a small value. Do not use
> > + * zero, KVM applies special heuristics for CPU startup when TSC is cleared.
> > + */
> > + if (cpu->tsc_clear_on_reset) {
> > + env->tsc = 1;
> > + }
> > 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;
> > @@ -6957,6 +6966,7 @@ static Property x86_cpu_properties[] = {
> > false),
> > DEFINE_PROP_BOOL("vmware-cpuid-freq", X86CPU, vmware_cpuid_freq, true),
> > DEFINE_PROP_BOOL("tcg-cpuid", X86CPU, expose_tcg, true),
> > + DEFINE_PROP_BOOL("tsc-clear-on-reset", X86CPU, tsc_clear_on_reset, true),
> > DEFINE_PROP_BOOL("x-migrate-smi-count", X86CPU, migrate_smi_count,
> > true),
> > /*
> > diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> > index e31e6bd8b8..66f7901729 100644
> > --- a/target/i386/cpu.h
> > +++ b/target/i386/cpu.h
> > @@ -1864,6 +1864,9 @@ struct ArchCPU {
> > /* Forcefully disable KVM PV features not exposed in guest CPUIDs */
> > bool kvm_pv_enforce_cpuid;
> >
> > + /* Clear TSC on reset */
> > + bool tsc_clear_on_reset;
> > +
> > /* Number of physical address bits supported */
> > uint32_t phys_bits;
> >
> > --
> > 2.35.1
> >
> >
>
> With regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
>
>
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-03-24 9:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 8:23 [PATCH] target/i386: introduce CPU property to work around Windows reset bug Paolo Bonzini
2022-03-24 9:13 ` Daniel P. Berrangé
2022-03-24 9:15 ` Daniel P. Berrangé [this message]
2022-03-24 9:42 ` Paolo Bonzini
2022-03-24 11:03 ` Daniel P. Berrangé
2022-03-24 11:24 ` Paolo Bonzini
2022-03-24 17:13 ` Paolo Bonzini
2022-03-24 17:37 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yjw2yvN1OHkmBb2X@redhat.com \
--to=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vrozenfe@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).