From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE457C433F5 for ; Sat, 25 Sep 2021 00:56:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 94FD5610EA for ; Sat, 25 Sep 2021 00:56:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347229AbhIYA5d (ORCPT ); Fri, 24 Sep 2021 20:57:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346490AbhIYA5V (ORCPT ); Fri, 24 Sep 2021 20:57:21 -0400 Received: from mail-qv1-xf4a.google.com (mail-qv1-xf4a.google.com [IPv6:2607:f8b0:4864:20::f4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3D2BC061767 for ; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) Received: by mail-qv1-xf4a.google.com with SMTP id w10-20020a0cb54a000000b0037a9848b92fso44747096qvd.0 for ; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=wCDTOmCATHVhirkJj1e9UGRNdETjcfm809lLJpA1KZ0=; b=NqlSHtDJsZY9ynz1iazGvEiDMeqk04glWuzCtUdaZ74/+oO9rjnWS76Uh5TCi8grB+ KwboA6njeSjTV+7uoE02X2FwYEkNPrLAm4qkXIZRVzJuxFafx32Mk5Xow/7WaARh1YAZ aC51w8eW6QKpvfDfIdD1udB75TJ4xUgQM915d2jcceUTh/hDb7mbGAiLnwAyqt0Y+WNF QpBy7FR47VOdDUwc186Fr9j28eODhANC/CUAjZvNZrR7fGsZs3zQzKM9xL4iXSTKlTtT +D4Y310QHpvHJHW02qI33BojoXY3YB8cjH1EF1eQmiciixtCRe97iPAZe1mITqWJtBmk YH1g== 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:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=wCDTOmCATHVhirkJj1e9UGRNdETjcfm809lLJpA1KZ0=; b=L121/BZauuyW+Mlwjn7qYrK6IwmKVqiAagh5rwFNBEUTN9/k70TMHq0+XS6L5+fHza Sz6pQpsOq/LQ3j9vd1aXuGTYO99gWboa0L2i9vFmLwZiSs92uNmSGG1ll6Twmd6EysWS NMkIcpFD9NqEtb932HMaQZJVcVVLeDzOWqVPwAwQKXUk4Q41JKTsibXu4pxLqCyDTr1j vUp2Cv+Mj6MVKYXgP/bGqmoVXfzUJdWj5DmMCxvgvXZwbpL3TA2K4TfXBe5EXPfCTWB3 2wzABKPbYz+YEZCbki4smcvNu7wUsGPthWPKL83LxEaVSS5aUIKJmis0oDb9igSBzCJH BoPA== X-Gm-Message-State: AOAM5310kZ9W6GjvLFATEtSZXCzoK0cBcXq+bFy4bqvHa1BW6tk9JUUy TAOGqBJoByYynHahPw5Bypdq4UvHkDU= X-Google-Smtp-Source: ABdhPJwAe8cto2GGuy35+RfGF59+NomWHsqVgBAWIRGsvWVII07cOgInTsUOlV2E2ha1qSQ9QAXX81/NXqE= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:90:200:4c72:89be:dba3:2bcb]) (user=seanjc job=sendgmr) by 2002:a05:6214:1046:: with SMTP id l6mr4932886qvr.6.1632531346015; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) Reply-To: Sean Christopherson Date: Fri, 24 Sep 2021 17:55:21 -0700 In-Reply-To: <20210925005528.1145584-1-seanjc@google.com> Message-Id: <20210925005528.1145584-8-seanjc@google.com> Mime-Version: 1.0 References: <20210925005528.1145584-1-seanjc@google.com> X-Mailer: git-send-email 2.33.0.685.g46640cef36-goog Subject: [PATCH 07/14] KVM: Don't block+unblock when halt-polling is successful 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 Invoke the arch hooks for block+unblock if and only if KVM actually attempts to block the vCPU. The only non-nop implementation is on arm64, and if halt-polling is successful, there is no need for arm64 to put/load the vGIC as KVM hasn't relinquished control of the vCPU in any way. The primary motivation is to allow future cleanup to split out "block" from "halt", but this is also likely a small performance boost on arm64 when halt-polling is successful. Adjust the post-block path to update "cur" after unblocking, i.e. include vGIC load time in halt_wait_ns and halt_wait_hist, so that the behavior is consistent. Moving just the pre-block arch hook would result in only the vGIC put latency being included in the halt_wait stats. There is no obvious evidence that one way or the other is correct, so just ensure KVM is consistent. Cc: Marc Zyngier Cc: James Morse Cc: Alexandru Elisei Cc: Suzuki K Poulose Signed-off-by: Sean Christopherson --- virt/kvm/kvm_main.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2015a1f532ce..f96cda8312f3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3232,8 +3232,6 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) bool waited = false; u64 block_ns; - kvm_arch_vcpu_blocking(vcpu); - start = cur = poll_end = ktime_get(); if (do_halt_poll) { ktime_t stop = ktime_add_ns(ktime_get(), vcpu->halt_poll_ns); @@ -3250,6 +3248,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) } while (kvm_vcpu_can_poll(cur, stop)); } + kvm_arch_vcpu_blocking(vcpu); prepare_to_rcuwait(&vcpu->wait); for (;;) { @@ -3262,6 +3261,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) schedule(); } finish_rcuwait(&vcpu->wait); + + kvm_arch_vcpu_unblocking(vcpu); + cur = ktime_get(); if (waited) { vcpu->stat.generic.halt_wait_ns += @@ -3269,8 +3271,8 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) KVM_STATS_LOG_HIST_UPDATE(vcpu->stat.generic.halt_wait_hist, ktime_to_ns(cur) - ktime_to_ns(poll_end)); } + out: - kvm_arch_vcpu_unblocking(vcpu); block_ns = ktime_to_ns(cur) - ktime_to_ns(start); /* -- 2.33.0.685.g46640cef36-goog From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F07BC433F5 for ; Sat, 25 Sep 2021 00:55:50 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 24FC461265 for ; Sat, 25 Sep 2021 00:55:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 24FC461265 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C13A54B133; Fri, 24 Sep 2021 20:55:49 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFZvsJlOYl6c; Fri, 24 Sep 2021 20:55:48 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6131B4B152; Fri, 24 Sep 2021 20:55:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 63B2B4B12C for ; Fri, 24 Sep 2021 20:55:47 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r18mIgBipmxt for ; Fri, 24 Sep 2021 20:55:46 -0400 (EDT) Received: from mail-qk1-f202.google.com (mail-qk1-f202.google.com [209.85.222.202]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 600624B136 for ; Fri, 24 Sep 2021 20:55:46 -0400 (EDT) Received: by mail-qk1-f202.google.com with SMTP id s18-20020a05620a255200b00433885d4fa7so44984737qko.4 for ; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=wCDTOmCATHVhirkJj1e9UGRNdETjcfm809lLJpA1KZ0=; b=NqlSHtDJsZY9ynz1iazGvEiDMeqk04glWuzCtUdaZ74/+oO9rjnWS76Uh5TCi8grB+ KwboA6njeSjTV+7uoE02X2FwYEkNPrLAm4qkXIZRVzJuxFafx32Mk5Xow/7WaARh1YAZ aC51w8eW6QKpvfDfIdD1udB75TJ4xUgQM915d2jcceUTh/hDb7mbGAiLnwAyqt0Y+WNF QpBy7FR47VOdDUwc186Fr9j28eODhANC/CUAjZvNZrR7fGsZs3zQzKM9xL4iXSTKlTtT +D4Y310QHpvHJHW02qI33BojoXY3YB8cjH1EF1eQmiciixtCRe97iPAZe1mITqWJtBmk YH1g== 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:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=wCDTOmCATHVhirkJj1e9UGRNdETjcfm809lLJpA1KZ0=; b=uT4ZvQEPSufgarZjD75WsRp2OuJh6i7rrgFyBZAiK1zIhHSVCnLN5c14tFpDFCY4WZ VRfY8uR8W9Kn2ZMfIxUidugpoOXHaorFultPHzvjNSyBeAldsjOPgMAiqjshFbDZwPKm ZTWousmeiskb7OkuTCgUeg0pQWxW1FL2jdnQLD9VswEi98wdLuizrJhETxhZ2WRFay89 hDnq9XG/fn73DSWliEDcD4fTijydKt9iIuI4Zuq5V1cTmJDXJCL0YDWM1QKOP697D2GE LQVQtDK3hduGY77QuHP6hN/bQm8PVat24Fi5VZv1MMr/X5kuW4367jZDR2XqdJuVV3LW a+JQ== X-Gm-Message-State: AOAM533zzHwbCJ72KQ32pZeLOPYiqO1szVkqoq9pDEdYJxgYbhsZ5lOI T4YV8sZbqxrGBnVDIPpbvgl4TVC6dyA= X-Google-Smtp-Source: ABdhPJwAe8cto2GGuy35+RfGF59+NomWHsqVgBAWIRGsvWVII07cOgInTsUOlV2E2ha1qSQ9QAXX81/NXqE= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:90:200:4c72:89be:dba3:2bcb]) (user=seanjc job=sendgmr) by 2002:a05:6214:1046:: with SMTP id l6mr4932886qvr.6.1632531346015; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) Date: Fri, 24 Sep 2021 17:55:21 -0700 In-Reply-To: <20210925005528.1145584-1-seanjc@google.com> Message-Id: <20210925005528.1145584-8-seanjc@google.com> Mime-Version: 1.0 References: <20210925005528.1145584-1-seanjc@google.com> X-Mailer: git-send-email 2.33.0.685.g46640cef36-goog Subject: [PATCH 07/14] KVM: Don't block+unblock when halt-polling is successful From: Sean Christopherson To: Marc Zyngier , Huacai Chen , Aleksandar Markovic , Paul Mackerras , Christian Borntraeger , Janosch Frank , Paolo Bonzini Cc: Wanpeng Li , kvm@vger.kernel.org, David Hildenbrand , Joerg Roedel , Cornelia Huck , linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, David Matlack , Vitaly Kuznetsov , Claudio Imbrenda , kvmarm@lists.cs.columbia.edu, Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Sean Christopherson List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Invoke the arch hooks for block+unblock if and only if KVM actually attempts to block the vCPU. The only non-nop implementation is on arm64, and if halt-polling is successful, there is no need for arm64 to put/load the vGIC as KVM hasn't relinquished control of the vCPU in any way. The primary motivation is to allow future cleanup to split out "block" from "halt", but this is also likely a small performance boost on arm64 when halt-polling is successful. Adjust the post-block path to update "cur" after unblocking, i.e. include vGIC load time in halt_wait_ns and halt_wait_hist, so that the behavior is consistent. Moving just the pre-block arch hook would result in only the vGIC put latency being included in the halt_wait stats. There is no obvious evidence that one way or the other is correct, so just ensure KVM is consistent. Cc: Marc Zyngier Cc: James Morse Cc: Alexandru Elisei Cc: Suzuki K Poulose Signed-off-by: Sean Christopherson --- virt/kvm/kvm_main.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2015a1f532ce..f96cda8312f3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3232,8 +3232,6 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) bool waited = false; u64 block_ns; - kvm_arch_vcpu_blocking(vcpu); - start = cur = poll_end = ktime_get(); if (do_halt_poll) { ktime_t stop = ktime_add_ns(ktime_get(), vcpu->halt_poll_ns); @@ -3250,6 +3248,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) } while (kvm_vcpu_can_poll(cur, stop)); } + kvm_arch_vcpu_blocking(vcpu); prepare_to_rcuwait(&vcpu->wait); for (;;) { @@ -3262,6 +3261,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) schedule(); } finish_rcuwait(&vcpu->wait); + + kvm_arch_vcpu_unblocking(vcpu); + cur = ktime_get(); if (waited) { vcpu->stat.generic.halt_wait_ns += @@ -3269,8 +3271,8 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) KVM_STATS_LOG_HIST_UPDATE(vcpu->stat.generic.halt_wait_hist, ktime_to_ns(cur) - ktime_to_ns(poll_end)); } + out: - kvm_arch_vcpu_unblocking(vcpu); block_ns = ktime_to_ns(cur) - ktime_to_ns(start); /* -- 2.33.0.685.g46640cef36-goog _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A390C433F5 for ; Sat, 25 Sep 2021 00:59:20 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 51FEB61029 for ; Sat, 25 Sep 2021 00:59:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 51FEB61029 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Reply-To:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:References :Mime-Version:Message-Id:In-Reply-To:Date:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SKj3xRQVriAzuyRHjytRuNrmUdzrOMtbnDqS07xZnA4=; b=GP3asK6C7o2h3J ZCwhkOORbqSJDVp9zCQxIISksKz3rqpz+Xl9LtVz2W25NMhWqFVl5nJmJ4Ul5Se9y9bSAutm3FJDI ms3ubqX4XJUhnf8eWqDbOJ9e7WoKgVvMyUn+ZgpHzB/T0jC0qYD4qsL5dF7UJFW/gsmYp6EMtTJXx b+Bl1KmQmdzYu18AA+iY5lKaNIt4gmhaj8R8003L3CQXduJPIV2ZxUkDOs6t30UdTzscEpwKOKNvG cF1lj4hsPWhIsiDc4TJsD9XaMhrYr9AaVPCbpv6rw6Z9yd/ApwXF2RBOExLV1daEqVN2bJbR2ZASy TYGXY5FEnDJhtdBMkepg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mTw0S-00FqaA-3R; Sat, 25 Sep 2021 00:57:32 +0000 Received: from mail-qt1-x849.google.com ([2607:f8b0:4864:20::849]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mTvyl-00Fpvx-EY for linux-arm-kernel@lists.infradead.org; Sat, 25 Sep 2021 00:55:48 +0000 Received: by mail-qt1-x849.google.com with SMTP id 13-20020ac8560d000000b0029f69548889so42321018qtr.3 for ; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=wCDTOmCATHVhirkJj1e9UGRNdETjcfm809lLJpA1KZ0=; b=NqlSHtDJsZY9ynz1iazGvEiDMeqk04glWuzCtUdaZ74/+oO9rjnWS76Uh5TCi8grB+ KwboA6njeSjTV+7uoE02X2FwYEkNPrLAm4qkXIZRVzJuxFafx32Mk5Xow/7WaARh1YAZ aC51w8eW6QKpvfDfIdD1udB75TJ4xUgQM915d2jcceUTh/hDb7mbGAiLnwAyqt0Y+WNF QpBy7FR47VOdDUwc186Fr9j28eODhANC/CUAjZvNZrR7fGsZs3zQzKM9xL4iXSTKlTtT +D4Y310QHpvHJHW02qI33BojoXY3YB8cjH1EF1eQmiciixtCRe97iPAZe1mITqWJtBmk YH1g== 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:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=wCDTOmCATHVhirkJj1e9UGRNdETjcfm809lLJpA1KZ0=; b=r0i66fX0wDvR5g5KHhOHCnF3QK2N7SzEpUHP7/VJqlVFPAnfmLj3MSlLup71cvvXif BYOR4M3JIX10OZRkImJtTds/gtH0wJR/dXjqkqDC5o8FMhUVpmqbdyGPemHHqVNOciLU 23df73x0qb7+wtznQ2dFwBqK9Ll/I8e4L7DnrCQI6qJcArslllh05yKmokkUt8kX6Ouj f1W/+c/ZfFk402/+59cFNxCpZNHmkQS3MfP7V5uWuv39kPyGvctRwbLgO3TJy3XWVEok IXrwr6mLMryPQEYZjGZZJZhIvKhc64m3ZsgtGwPNPvPRaIMYyyEJpjGESgEzU+ZCEHdL 0m4Q== X-Gm-Message-State: AOAM5309PnVK76Vyo1fl+GZco/nm4ETvjz51+WOG+jc+GjOHUv29f7BA Xi9NOluUAedvdHU04DKVv4vpD4l9Ha4= X-Google-Smtp-Source: ABdhPJwAe8cto2GGuy35+RfGF59+NomWHsqVgBAWIRGsvWVII07cOgInTsUOlV2E2ha1qSQ9QAXX81/NXqE= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:90:200:4c72:89be:dba3:2bcb]) (user=seanjc job=sendgmr) by 2002:a05:6214:1046:: with SMTP id l6mr4932886qvr.6.1632531346015; Fri, 24 Sep 2021 17:55:46 -0700 (PDT) Date: Fri, 24 Sep 2021 17:55:21 -0700 In-Reply-To: <20210925005528.1145584-1-seanjc@google.com> Message-Id: <20210925005528.1145584-8-seanjc@google.com> Mime-Version: 1.0 References: <20210925005528.1145584-1-seanjc@google.com> X-Mailer: git-send-email 2.33.0.685.g46640cef36-goog Subject: [PATCH 07/14] KVM: Don't block+unblock when halt-polling is successful 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210924_175547_552282_A7D0A2DE X-CRM114-Status: GOOD ( 13.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Sean Christopherson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Invoke the arch hooks for block+unblock if and only if KVM actually attempts to block the vCPU. The only non-nop implementation is on arm64, and if halt-polling is successful, there is no need for arm64 to put/load the vGIC as KVM hasn't relinquished control of the vCPU in any way. The primary motivation is to allow future cleanup to split out "block" from "halt", but this is also likely a small performance boost on arm64 when halt-polling is successful. Adjust the post-block path to update "cur" after unblocking, i.e. include vGIC load time in halt_wait_ns and halt_wait_hist, so that the behavior is consistent. Moving just the pre-block arch hook would result in only the vGIC put latency being included in the halt_wait stats. There is no obvious evidence that one way or the other is correct, so just ensure KVM is consistent. Cc: Marc Zyngier Cc: James Morse Cc: Alexandru Elisei Cc: Suzuki K Poulose Signed-off-by: Sean Christopherson --- virt/kvm/kvm_main.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2015a1f532ce..f96cda8312f3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3232,8 +3232,6 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) bool waited = false; u64 block_ns; - kvm_arch_vcpu_blocking(vcpu); - start = cur = poll_end = ktime_get(); if (do_halt_poll) { ktime_t stop = ktime_add_ns(ktime_get(), vcpu->halt_poll_ns); @@ -3250,6 +3248,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) } while (kvm_vcpu_can_poll(cur, stop)); } + kvm_arch_vcpu_blocking(vcpu); prepare_to_rcuwait(&vcpu->wait); for (;;) { @@ -3262,6 +3261,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) schedule(); } finish_rcuwait(&vcpu->wait); + + kvm_arch_vcpu_unblocking(vcpu); + cur = ktime_get(); if (waited) { vcpu->stat.generic.halt_wait_ns += @@ -3269,8 +3271,8 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) KVM_STATS_LOG_HIST_UPDATE(vcpu->stat.generic.halt_wait_hist, ktime_to_ns(cur) - ktime_to_ns(poll_end)); } + out: - kvm_arch_vcpu_unblocking(vcpu); block_ns = ktime_to_ns(cur) - ktime_to_ns(start); /* -- 2.33.0.685.g46640cef36-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Sat, 25 Sep 2021 00:55:21 +0000 Subject: [PATCH 07/14] KVM: Don't block+unblock when halt-polling is successful Message-Id: <20210925005528.1145584-8-seanjc@google.com> List-Id: References: <20210925005528.1145584-1-seanjc@google.com> In-Reply-To: <20210925005528.1145584-1-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 Invoke the arch hooks for block+unblock if and only if KVM actually attempts to block the vCPU. The only non-nop implementation is on arm64, and if halt-polling is successful, there is no need for arm64 to put/load the vGIC as KVM hasn't relinquished control of the vCPU in any way. The primary motivation is to allow future cleanup to split out "block" from "halt", but this is also likely a small performance boost on arm64 when halt-polling is successful. Adjust the post-block path to update "cur" after unblocking, i.e. include vGIC load time in halt_wait_ns and halt_wait_hist, so that the behavior is consistent. Moving just the pre-block arch hook would result in only the vGIC put latency being included in the halt_wait stats. There is no obvious evidence that one way or the other is correct, so just ensure KVM is consistent. Cc: Marc Zyngier Cc: James Morse Cc: Alexandru Elisei Cc: Suzuki K Poulose Signed-off-by: Sean Christopherson --- virt/kvm/kvm_main.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 2015a1f532ce..f96cda8312f3 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3232,8 +3232,6 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) bool waited = false; u64 block_ns; - kvm_arch_vcpu_blocking(vcpu); - start = cur = poll_end = ktime_get(); if (do_halt_poll) { ktime_t stop = ktime_add_ns(ktime_get(), vcpu->halt_poll_ns); @@ -3250,6 +3248,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) } while (kvm_vcpu_can_poll(cur, stop)); } + kvm_arch_vcpu_blocking(vcpu); prepare_to_rcuwait(&vcpu->wait); for (;;) { @@ -3262,6 +3261,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) schedule(); } finish_rcuwait(&vcpu->wait); + + kvm_arch_vcpu_unblocking(vcpu); + cur = ktime_get(); if (waited) { vcpu->stat.generic.halt_wait_ns +@@ -3269,8 +3271,8 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu) KVM_STATS_LOG_HIST_UPDATE(vcpu->stat.generic.halt_wait_hist, ktime_to_ns(cur) - ktime_to_ns(poll_end)); } + out: - kvm_arch_vcpu_unblocking(vcpu); block_ns = ktime_to_ns(cur) - ktime_to_ns(start); /* -- 2.33.0.685.g46640cef36-goog