summaryrefslogtreecommitdiffstats
path: root/tools/objtool/elf.c
diff options
context:
space:
mode:
authorVitaly Kuznetsov <vkuznets@redhat.com>2022-07-12 15:50:09 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2022-07-14 07:44:05 -0400
commit99482726452bdf8be9325199022b17fa6d7d58fe (patch)
tree8e883f0314338b2c752c7a1a1c090557c38e9240 /tools/objtool/elf.c
parente0f3f46e42064a51573914766897b4ab95d943e3 (diff)
downloadlinux-99482726452bdf8be9325199022b17fa6d7d58fe.tar.bz2
KVM: nVMX: Always enable TSC scaling for L2 when it was enabled for L1
Windows 10/11 guests with Hyper-V role (WSL2) enabled are observed to hang upon boot or shortly after when a non-default TSC frequency was set for L1. The issue is observed on a host where TSC scaling is supported. The problem appears to be that Windows doesn't use TSC frequency for its guests even when the feature is advertised and KVM filters SECONDARY_EXEC_TSC_SCALING out when creating L2 controls from L1's. This leads to L2 running with the default frequency (matching host's) while L1 is running with an altered one. Keep SECONDARY_EXEC_TSC_SCALING in secondary exec controls for L2 when it was set for L1. TSC_MULTIPLIER is already correctly computed and written by prepare_vmcs02(). Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20220712135009.952805-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/objtool/elf.c')
0 files changed, 0 insertions, 0 deletions