qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] target/i386: introduce CPU property to work around Windows r


From: Daniel P . Berrangé
Subject: Re: [PATCH] target/i386: introduce CPU property to work around Windows reset bug
Date: Thu, 24 Mar 2022 11:03:28 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

On Thu, Mar 24, 2022 at 10:42:22AM +0100, Paolo Bonzini wrote:
> On 3/24/22 10:15, Daniel P. Berrangé wrote:
> > 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.
> 
> Well, I have a patch to turn it on/off in Libvirt and I also planned to
> leave it off by default in RHEL patch updates (I'm not tying it to the
> machine type because it's not a guest ABI change).
> 
> I am myself conflicted on whether to leave it on or off in QEMU.  For
> example you could use the TSC to measure how long the VM has been up, but
> this patch makes that not work anymore.  Considering that the bug requires
> literally 2-3 months of VM uptime to manifest itself, it might be better to
> set up the property in libosinfo and only for Windows guests.
> 
> Also, since it is a bug in Windows, it will hopefully be fixed sooner or
> later.

In the libvirt patches you mentioned VMWare has the same workaround
available, and not enabled by default. I looked up this VMWare setting
and it is interesting reading:

  https://kb.vmware.com/s/article/2092807

Of particular note

  "This only applies to virtual machine hardware version 10 as Windows
   resets the TSC on all CPUs on virtual machines with older hardware
   versions (which do not support hypervisor.cpuid.v2)."

do you know what they mean when they refer to 'hypervisor.cpuid.v2'
here ? I wonder if it gives any hints as to a root cause that could
be fixed ?

This hardware version 10 is well old - their current hardware version
is 19, so it seems to show the implemented some built-in fix in newer
hardware versions (their equiv of machine types). The vmware setting
dates from 2013, and if I read that kbase correctly isn't needed on
their modern hardware versions. Or maybe 
monitor_control.enable_softResetClearTSC
became the default in newer hardware versions ?

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]