summaryrefslogtreecommitdiff
path: root/arch/x86/kvm/lapic.c
diff options
context:
space:
mode:
authorVitaly Kuznetsov <vkuznets@redhat.com>2019-03-20 18:43:20 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2019-04-18 18:53:18 +0200
commitda66761c2d93a46270d69001abb5692717495a68 (patch)
tree01e52fd674115abfde2a49f61c116fb0566f53e1 /arch/x86/kvm/lapic.c
parentc09d65d9eab69985c75f98ed64541229f6fa9aa6 (diff)
x86: kvm: hyper-v: deal with buggy TLB flush requests from WS2012
It was reported that with some special Multi Processor Group configuration, e.g: bcdedit.exe /set groupsize 1 bcdedit.exe /set maxgroup on bcdedit.exe /set groupaware on for a 16-vCPU guest WS2012 shows BSOD on boot when PV TLB flush mechanism is in use. Tracing kvm_hv_flush_tlb immediately reveals the issue: kvm_hv_flush_tlb: processor_mask 0x0 address_space 0x0 flags 0x2 The only flag set in this request is HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES, however, processor_mask is 0x0 and no HV_FLUSH_ALL_PROCESSORS is specified. We don't flush anything and apparently it's not what Windows expects. TLFS doesn't say anything about such requests and newer Windows versions seem to be unaffected. This all feels like a WS2012 bug, which is, however, easy to workaround in KVM: let's flush everything when we see an empty flush request, over-flushing doesn't hurt. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/x86/kvm/lapic.c')
0 files changed, 0 insertions, 0 deletions