|
From: | Paolo Bonzini |
Subject: | Re: [PATCH] target/i386: introduce CPU property to work around Windows reset bug |
Date: | Thu, 24 Mar 2022 12:24:02 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 |
On 3/24/22 12:03, Daniel P. Berrangé wrote:
"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 ?
The difference between hardware versions probably is that older versions do not support Hyper-V enlightenments. The bug does not happen if Windows uses the RTC for timekeeping, which is consistent with the description above.
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 ?
Yeah, maybe it became the default but they didn't want to change previously-released hardware versions. So that would be basically treating it as an ABI change, and only enable it in 7.0 machine types.
That said, the VMware kbase does paint a slightly different picture. It implies that starting with hardware version 11 rebooting Windows is done through a hard reset instead of INIT. I'm not sure how that would be done, but in the meanwhile our fix should take care of do_cpu_init as well.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |