Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2182290pxb; Fri, 24 Sep 2021 23:42:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmmfnMyteA42RVCCudCzCCqUVkn0MGBMz7gytvDkTo1+h1QjUEHIuPapMOnlbyR5+7YAxl X-Received: by 2002:a5d:9cd4:: with SMTP id w20mr12500159iow.172.1632552144293; Fri, 24 Sep 2021 23:42:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632552144; cv=none; d=google.com; s=arc-20160816; b=s7PPjzbvBRwQapSmb/x+QK2bYluDSTmVwCxI97O/KjAz6wHFlC6HeP31a3BW0ZQyDr LCpl+fmw0WVGl5mkbOCpBPEY/932jYilY/7MFHaxoPcZHi6ZkLs/IS20SHCZGZLFuzLR TpoxX5STqahedFHRguMEpnf+TWfNK6nrWU+xhTJ22ENIc8O6wor5yPOEWSMdQ4ci8MtH /mOEA2lGfj5dp+dlissSbdYVV2Er4JU31WAQ2vqSM+EvxFVsra7g8UNPkyrmBAwmCOUh qYqyhGasU2qIehF0ynCzS6KtG9NWpuxmWHCaEyQq1AJU7Wv3I4LO9Uvr4Q78/4VXCUgm rZWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :reply-to:dkim-signature; bh=7raooij+tUym7W5s5WPrsLkrWPVticCVkKY3RWsiNDM=; b=Pk75im8tRBogEui9nZ6MuE2k9DILEkSeywFtmsKOnng7DeioTg2XHc2Wy50yvJfvAm C8DqrSQsc4/EQ48LiqZCf+3PrSH/YHalaG6vUbLyWRjJlehWKNMXwp4Su9OxZKlAJvyu 6Rxf3fs88etO5bBdNMAGAxxiAsDZ8H0VQR/oqov8O1iWJwvWLP9c78pv3qWOuGyDKR3t xm6WGKCehN7qmQvwK5N9IGRDlyBZsxopiVPbz7zpIn4HGQ4aLruwgXiknWhOxpPJH53x jxHqzZynD9ITtBZobs62Be8OWPhQc5TxYoCQauML8v2twb8+VTJ+xKV0RIT29eDPzFuK U4pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DXmlShHb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h2si16936557iow.79.2021.09.24.23.42.12; Fri, 24 Sep 2021 23:42:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=DXmlShHb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345983AbhIYA5I (ORCPT + 99 others); Fri, 24 Sep 2021 20:57:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40242 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233410AbhIYA5F (ORCPT ); Fri, 24 Sep 2021 20:57:05 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9F03C061613 for ; Fri, 24 Sep 2021 17:55:31 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id y134-20020a25dc8c000000b0059f0301df0fso5793175ybe.21 for ; Fri, 24 Sep 2021 17:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:message-id:mime-version:subject:from:to:cc; bh=7raooij+tUym7W5s5WPrsLkrWPVticCVkKY3RWsiNDM=; b=DXmlShHbjvZa1JvxxvOqKfYKe30mtQRur87j+123oY2dFsBNlIAv8O9qEBNpSOGVM0 b5Sl+lbCoTOZX+zxJ51FQGhzcy9kOU+kuN3HT7C+f5nB6pN5R9AkQ8rfnjTjbSc6y1L3 1xXBLePNa9IJaU5EZa6ilhTbqnfNBkXudDaPUTNvEb8RjoCOqehEtkbp9fcq+twCr1dj 7pQFp14KUjSeBu0Lomx7YgO5vlp+0uTYliIei7NH6p2gACqnEuNLOy869NtJ5XSjME8N QoN0wBA2Bv2bcnfhLjSPkQbfYQGKsKIy45up5bnYKrvy1J3XDWY6xOjC4rNSR6s7vMuY cddw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:message-id:mime-version:subject :from:to:cc; bh=7raooij+tUym7W5s5WPrsLkrWPVticCVkKY3RWsiNDM=; b=Pzj2vvTLyJZ3IcMSiBoPBH4SAY5lvxY1BpEg2ZDcI8UZ34ny0MPrSPav9d5xI0itIe CBw9OtoCPo7AVpUB3xyegwZCDAyoBcMCIK0iun3b22PgOAyPWwZvRhHP2+RT4OYcwVZt fdLwPOMzvUrOnWvnrfqDG0GSuP6TDbS9sOu/+Je/RZLGeAUi5+E7hpsB6IHSZsF8qs7i s/DVyYzZ8vxozMLQvDhfelt7wcHzulGq7FlyBNn10wI3oHYeFYB/1cQjtiN6FpUb4JAr mUwY6OyWqBt96KtAq9mqzIENQLcuiEBw4jLnX2CQhrkEkWHg50s5/ynfoEBOU94cZpFF pPGw== X-Gm-Message-State: AOAM532uRBpoU7b1+jHEVUkHmlMG4B0aVMIvRF7jxA+HRPrmoBa18tGI 1b/JobNwZFXIFqwHCmc845o4YeIiG+4= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:90:200:4c72:89be:dba3:2bcb]) (user=seanjc job=sendgmr) by 2002:a25:d482:: with SMTP id m124mr15615049ybf.73.1632531330879; Fri, 24 Sep 2021 17:55:30 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 24 Sep 2021 17:55:14 -0700 Message-Id: <20210925005528.1145584-1-seanjc@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.33.0.685.g46640cef36-goog Subject: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a new stat From: Sean Christopherson To: Marc Zyngier , Huacai Chen , Aleksandar Markovic , Paul Mackerras , Christian Borntraeger , Janosch Frank , Paolo Bonzini Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , David Hildenbrand , Cornelia Huck , Claudio Imbrenda , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , Jing Zhang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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