This series was prompted by observations of HLT-exiting when debugging
a throughput issue related to posted interrupts. When KVM is running in
a nested scenario, a rather surprising number of HLT exits occur with an
unmasked interrupt already pending. I didn't debug too deeply into the
guest side of things, but I suspect what is happening is that it's fairly
easy for L2 to be interrupted (by L1 or L0) between checking if it (the
CPU) should enter an idle state and actually executing STI;HLT.
AFAICT, a non-nested setup doesn't benefit much, if at all. But, I don't
see any downside to checking for a wake event in the fastpath, e.g. it's
basically a "zero" time halt-polling mechanism.
The other patches fix flaws found by inspection when adding HLT-exiting
to the faspath.
Note, the userspace-exit logic is basically untested, i.e. I probably
need to write a selftest...
Sean Christopherson (5):
KVM: x86: Re-enter guest if WRMSR(X2APIC_ICR) fastpath is successful
KVM: x86: Dedup fastpath MSR post-handling logic
KVM: x86: Exit to userspace if fastpath triggers one on instruction
skip
KVM: x86: Reorganize code in x86.c to co-locate vCPU blocking/running
helpers
KVM: x86: Add fastpath handling of HLT VM-Exits
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/svm/svm.c | 13 +-
arch/x86/kvm/vmx/vmx.c | 2 +
arch/x86/kvm/x86.c | 319 +++++++++++++++++---------------
arch/x86/kvm/x86.h | 1 +
5 files changed, 188 insertions(+), 148 deletions(-)
base-commit: 332d2c1d713e232e163386c35a3ba0c1b90df83f
--
2.46.0.rc2.264.g509ed76dc8-goog
