summaryrefslogtreecommitdiff
path: root/arch/x86/kernel/crash_dump_32.c
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2024-08-02 12:51:20 -0700
committerSean Christopherson <seanjc@google.com>2024-08-29 19:50:22 -0700
commit1876dd69dfe8c29e249070b0e4dc941fc15ac1e4 (patch)
treed47a434ec85edf7ead84b3e19f2ce9edb1764a0f /arch/x86/kernel/crash_dump_32.c
parent70cdd2385106a91675ee0ba58facde0254597416 (diff)
KVM: x86: Add fastpath handling of HLT VM-Exits
Add a fastpath for HLT VM-Exits by immediately re-entering the guest if it has a pending wake event. When virtual interrupt delivery is enabled, i.e. when KVM doesn't need to manually inject interrupts, this allows KVM to stay in the fastpath run loop when a vIRQ arrives between the guest doing CLI and STI;HLT. Without AMD's Idle HLT-intercept support, the CPU generates a HLT VM-Exit even though KVM will immediately resume the guest. Note, on bare metal, it's relatively uncommon for a modern guest kernel to actually trigger this scenario, as the window between the guest checking for a wake event and committing to HLT is quite small. But in a nested environment, the timings change significantly, e.g. rudimentary testing showed that ~50% of HLT exits where HLT-polling was successful would be serviced by this fastpath, i.e. ~50% of the time that a nested vCPU gets a wake event before KVM schedules out the vCPU, the wake event was pending even before the VM-Exit. Link: https://lore.kernel.org/all/20240528041926.3989-3-manali.shukla@amd.com Link: https://lore.kernel.org/r/20240802195120.325560-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'arch/x86/kernel/crash_dump_32.c')
0 files changed, 0 insertions, 0 deletions