Message-Id: <20210925005528.1145584-1-seanjc@google.com>
Date:   Fri, 24 Sep 2021 17:55:14 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Marc Zyngier <maz@...nel.org>, Huacai Chen <chenhuacai@...nel.org>,
        Aleksandar Markovic <aleksandar.qemu.devel@...il.com>,
        Paul Mackerras <paulus@...abs.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     James Morse <james.morse@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        David Hildenbrand <david@...hat.com>,
        Cornelia Huck <cohuck@...hat.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
        linux-mips@...r.kernel.org, kvm@...r.kernel.org,
        kvm-ppc@...r.kernel.org, linux-kernel@...r.kernel.org,
        David Matlack <dmatlack@...gle.com>,
        Jing Zhang <jingzhangos@...gle.com>
Subject: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a new stat

The main purpose of this series is differentiate between "halt" and a more
generic "block", where "halt" aligns with x86's HLT instruction, the
halt-polling mechanisms, and associated stats, and "block" means any guest
action that causes the vCPU to block/wait.

This series arose out of a discussion over adding a stat to track if a
vCPU is blocked/halted[*].  The TL;DR of the discussion is that x86 has
several non-halt "wait" states, and arguably those states should not
participate in halt-polling.  In practice, it really doesn't matter from
a functionality perspective because there are typically so few occurences
of the non-halt waits that they're in the noise compared to the number of
actual HLTs, especially for a long-running VM.  So, my justification for
the rename is that because it doesn't truly affect functionality, KVM
might as well be technically correct and only use halt-polling for HLT.

The other annoyance this series addresses is that KVM mixes "halt" and
"block", e.g. the existing function is kvm_vcpu_block(), but all the stats
and the tracepoint use "halt".  Ideally, KVM would probably avoid "block"
altogether as people often think of "blocked" as meaning the vCPU is
blocked due to _host_ activity.  But I don't have a better alternative,
e.g. "halt" is obviously taken, "wait" is equivalent to "halt" on arm64,
"stop" has specific meaning on s390, etc...  I tried to address the host
vs. guest issue by naming the new stat "blocking" instead of "blocked",
e.g. to convey that the vCPU is "actively blocking" instead of "being
blocked".

Patch 01 fixes a theoretical, benign s390 bug, and sets the stage for
additional cleanups.

Patches 02-04 reconcile discrepancies in when KVM considers halt-polling
to be "successful".  Some stats consider it a success so long as KVM
doesn't schedule() away, others consider it a success if and only if a
wake event is detected in the halt-polling loop.

Patches 05-06 are prep cleanup to split out the core "block" routine.

Patch 07 is more prep, and should also be a small perf optimization for
halt-polling on arm64.

Patch 08 is x86 cleanup to free up the name kvm_vcpu_halt().

Patches 09-10 rename the existing kvm_vcpu_block() to kvm_vcpu_halt(), and
split out the core "block" routine to a new helper.

Patches 11-12 are minor cleanups to avoid unnecessary ktime_get().

Patches 13-14 convert non-HLT x86 flows to use kvm_vcpu_block().

[*] https://lkml.kernel.org/r/20210817230508.142907-1-jingzhangos@google.com

Jing Zhang (1):
  KVM: stats: Add stat to detect if vcpu is currently blocking

Sean Christopherson (13):
  KVM: s390: Ensure kvm_arch_no_poll() is read once when blocking vCPU
  KVM: Update halt-polling stats if and only if halt-polling was
    attempted
  KVM: Refactor and document halt-polling stats update helper
  KVM: Reconcile discrepancies in halt-polling stats
  KVM: s390: Clear valid_wakeup in kvm_s390_handle_wait(), not in arch
    hook
  KVM: Drop obsolete kvm_arch_vcpu_block_finish()
  KVM: Don't block+unblock when halt-polling is successful
  KVM: x86: Tweak halt emulation helper names to free up kvm_vcpu_halt()
  KVM: Rename kvm_vcpu_block() => kvm_vcpu_halt()
  KVM: Split out a kvm_vcpu_block() helper from kvm_vcpu_halt()
  KVM: Don't redo ktime_get() when calculating halt-polling
    stop/deadline
  KVM: x86: Directly block (instead of "halting") UNINITIALIZED vCPUs
  KVM: x86: Invoke kvm_vcpu_block() directly for non-HALTED wait states

 arch/arm64/include/asm/kvm_host.h   |   1 -
 arch/arm64/kvm/arch_timer.c         |   2 +-
 arch/arm64/kvm/handle_exit.c        |   4 +-
 arch/arm64/kvm/psci.c               |   2 +-
 arch/mips/include/asm/kvm_host.h    |   1 -
 arch/mips/kvm/emulate.c             |   2 +-
 arch/powerpc/include/asm/kvm_host.h |   1 -
 arch/powerpc/kvm/book3s_pr.c        |   2 +-
 arch/powerpc/kvm/book3s_pr_papr.c   |   2 +-
 arch/powerpc/kvm/booke.c            |   2 +-
 arch/powerpc/kvm/powerpc.c          |   2 +-
 arch/s390/include/asm/kvm_host.h    |   2 -
 arch/s390/kvm/interrupt.c           |   3 +-
 arch/s390/kvm/kvm-s390.c            |   7 +-
 arch/x86/include/asm/kvm_host.h     |   4 +-
 arch/x86/kvm/vmx/nested.c           |   2 +-
 arch/x86/kvm/vmx/vmx.c              |   4 +-
 arch/x86/kvm/x86.c                  |  25 ++++--
 include/linux/kvm_host.h            |   6 +-
 include/linux/kvm_types.h           |   1 +
 virt/kvm/kvm_main.c                 | 131 +++++++++++++++++-----------
 21 files changed, 118 insertions(+), 88 deletions(-)

-- 
2.33.0.685.g46640cef36-goog

Powered by blists - more mailing lists