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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

Paolo