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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EC67C43217 for ; Tue, 15 Nov 2022 03:29:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232616AbiKOD3F (ORCPT ); Mon, 14 Nov 2022 22:29:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229802AbiKOD3D (ORCPT ); Mon, 14 Nov 2022 22:29:03 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A90A9624C; Mon, 14 Nov 2022 19:28:59 -0800 (PST) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NBBPz29c4zqSHG; Tue, 15 Nov 2022 11:25:11 +0800 (CST) Received: from [10.174.187.128] (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 15 Nov 2022 11:28:56 +0800 Subject: Re: disabling halt polling broken? (was Re: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a new stat) To: Sean Christopherson , Paolo Bonzini CC: Wanpeng Li , kvm , David Hildenbrand , "Kernel Mailing List, Linux" , Paul Mackerras , Claudio Imbrenda , KVM ARM , Janosch Frank , Marc Zyngier , Joerg Roedel , Huacai Chen , Christian Borntraeger , Aleksandar Markovic , Jon Cargille , kvm-ppc , David Matlack , linux-arm-kernel , Jim Mattson , Cornelia Huck , "open list:MIPS" , Vitaly Kuznetsov References: <20210925005528.1145584-1-seanjc@google.com> <03f2f5ab-e809-2ba5-bd98-3393c3b843d2@de.ibm.com> <43e42f5c-9d9f-9e8b-3a61-9a053a818250@de.ibm.com> From: "wangyanan (Y)" Message-ID: <32810c89-44c6-6780-9d05-e49f6b897b6e@huawei.com> Date: Tue, 15 Nov 2022 11:28:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sean, Paolo, I recently also notice the behavior change of param halt_poll_ns. Now it loses the ability to: 1) dynamically disable halt polling for all the running VMs by `echo 0 > /sys` 2) dynamically adjust the halt polling interval for all the running VMs by `echo * > /sys` While in our cases, we usually use above two abilities, and KVM_CAP_HALT_POLL is not used yet. On 2021/9/28 1:33, Sean Christopherson wrote: > On Mon, Sep 27, 2021, Paolo Bonzini wrote: >> On Mon, Sep 27, 2021 at 5:17 PM Christian Borntraeger >> wrote: >>>> So I think there are two possibilities that makes sense: >>>> >>>> * track what is using KVM_CAP_HALT_POLL, and make writes to halt_poll_ns follow that >>> what about using halt_poll_ns for those VMs that did not uses KVM_CAP_HALT_POLL and the private number for those that did. >> Yes, that's what I meant. David pointed out that doesn't allow you to >> disable halt polling altogether, but for that you can always ask each >> VM's userspace one by one, or just not use KVM_CAP_HALT_POLL. (Also, I >> don't know about Google's usecase, but mine was actually more about >> using KVM_CAP_HALT_POLL to *disable* halt polling on some VMs!). > I kinda like the idea if special-casing halt_poll_ns=0, e.g. for testing or > in-the-field mitigation if halt-polling is broken. It'd be trivial to support, e.g. Do we have any plan to repost the diff as a fix? I would be very nice that this issue can be solved. Besides, I think we may need some Doc for users to describe how halt_poll_ns works with KVM_CAP_HALT_POLL, like "Documentation/virt/guest-halt-polling.rst". > @@ -3304,19 +3304,23 @@ void kvm_vcpu_halt(struct kvm_vcpu *vcpu) > update_halt_poll_stats(vcpu, start, poll_end, !waited); > > if (halt_poll_allowed) { > + max_halt_poll_ns = vcpu->kvm->max_halt_poll_ns; > + if (!max_halt_poll_ns || !halt_poll_ns) <------ squish the max if halt_poll_ns==0 > + max_halt_poll_ns = halt_poll_ns; > + Does this mean that KVM_CAP_HALT_POLL will not be able to disable halt polling for a VM individually when halt_poll_ns !=0? > if (!vcpu_valid_wakeup(vcpu)) { > shrink_halt_poll_ns(vcpu); > - } else if (vcpu->kvm->max_halt_poll_ns) { > + } else if (max_halt_poll_ns) { > if (halt_ns <= vcpu->halt_poll_ns) > ; > /* we had a long block, shrink polling */ > else if (vcpu->halt_poll_ns && > - halt_ns > vcpu->kvm->max_halt_poll_ns) > + halt_ns > max_halt_poll_ns) > shrink_halt_poll_ns(vcpu); > /* we had a short halt and our poll time is too small */ > - else if (vcpu->halt_poll_ns < vcpu->kvm->max_halt_poll_ns && > - halt_ns < vcpu->kvm->max_halt_poll_ns) > - grow_halt_poll_ns(vcpu); > + else if (vcpu->halt_poll_ns < max_halt_poll_ns && > + halt_ns < max_halt_poll_ns) > + grow_halt_poll_ns(vcpu, max_halt_poll_ns); > } else { > vcpu->halt_poll_ns = 0; > } > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > . Thanks, Yanan 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10D57C4332F for ; Tue, 15 Nov 2022 03:29:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7D0334B8A9; Mon, 14 Nov 2022 22:29:07 -0500 (EST) 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 VRaAX4bNRbIB; Mon, 14 Nov 2022 22:29:05 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 8EACA4B8AD; Mon, 14 Nov 2022 22:29:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B7CE34B8A9 for ; Mon, 14 Nov 2022 22:29:04 -0500 (EST) 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 Ew0je31NX6dR for ; Mon, 14 Nov 2022 22:29:02 -0500 (EST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E2FAE4B89C for ; Mon, 14 Nov 2022 22:29:01 -0500 (EST) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NBBPz29c4zqSHG; Tue, 15 Nov 2022 11:25:11 +0800 (CST) Received: from [10.174.187.128] (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 15 Nov 2022 11:28:56 +0800 Subject: Re: disabling halt polling broken? (was Re: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a new stat) To: Sean Christopherson , Paolo Bonzini References: <20210925005528.1145584-1-seanjc@google.com> <03f2f5ab-e809-2ba5-bd98-3393c3b843d2@de.ibm.com> <43e42f5c-9d9f-9e8b-3a61-9a053a818250@de.ibm.com> From: "wangyanan (Y)" Message-ID: <32810c89-44c6-6780-9d05-e49f6b897b6e@huawei.com> Date: Tue, 15 Nov 2022 11:28:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected Cc: Cornelia Huck , Wanpeng Li , Janosch Frank , kvm , David Hildenbrand , Marc Zyngier , Joerg Roedel , Huacai Chen , "Kernel Mailing List, Linux" , kvm-ppc , "open list:MIPS" , Paul Mackerras , Christian Borntraeger , Aleksandar Markovic , Jon Cargille , David Matlack , Vitaly Kuznetsov , Claudio Imbrenda , KVM ARM , linux-arm-kernel , Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Sean, Paolo, I recently also notice the behavior change of param halt_poll_ns. Now it loses the ability to: 1) dynamically disable halt polling for all the running VMs by `echo 0 > /sys` 2) dynamically adjust the halt polling interval for all the running VMs by `echo * > /sys` While in our cases, we usually use above two abilities, and KVM_CAP_HALT_POLL is not used yet. On 2021/9/28 1:33, Sean Christopherson wrote: > On Mon, Sep 27, 2021, Paolo Bonzini wrote: >> On Mon, Sep 27, 2021 at 5:17 PM Christian Borntraeger >> wrote: >>>> So I think there are two possibilities that makes sense: >>>> >>>> * track what is using KVM_CAP_HALT_POLL, and make writes to halt_poll_ns follow that >>> what about using halt_poll_ns for those VMs that did not uses KVM_CAP_HALT_POLL and the private number for those that did. >> Yes, that's what I meant. David pointed out that doesn't allow you to >> disable halt polling altogether, but for that you can always ask each >> VM's userspace one by one, or just not use KVM_CAP_HALT_POLL. (Also, I >> don't know about Google's usecase, but mine was actually more about >> using KVM_CAP_HALT_POLL to *disable* halt polling on some VMs!). > I kinda like the idea if special-casing halt_poll_ns=0, e.g. for testing or > in-the-field mitigation if halt-polling is broken. It'd be trivial to support, e.g. Do we have any plan to repost the diff as a fix? I would be very nice that this issue can be solved. Besides, I think we may need some Doc for users to describe how halt_poll_ns works with KVM_CAP_HALT_POLL, like "Documentation/virt/guest-halt-polling.rst". > @@ -3304,19 +3304,23 @@ void kvm_vcpu_halt(struct kvm_vcpu *vcpu) > update_halt_poll_stats(vcpu, start, poll_end, !waited); > > if (halt_poll_allowed) { > + max_halt_poll_ns = vcpu->kvm->max_halt_poll_ns; > + if (!max_halt_poll_ns || !halt_poll_ns) <------ squish the max if halt_poll_ns==0 > + max_halt_poll_ns = halt_poll_ns; > + Does this mean that KVM_CAP_HALT_POLL will not be able to disable halt polling for a VM individually when halt_poll_ns !=0? > if (!vcpu_valid_wakeup(vcpu)) { > shrink_halt_poll_ns(vcpu); > - } else if (vcpu->kvm->max_halt_poll_ns) { > + } else if (max_halt_poll_ns) { > if (halt_ns <= vcpu->halt_poll_ns) > ; > /* we had a long block, shrink polling */ > else if (vcpu->halt_poll_ns && > - halt_ns > vcpu->kvm->max_halt_poll_ns) > + halt_ns > max_halt_poll_ns) > shrink_halt_poll_ns(vcpu); > /* we had a short halt and our poll time is too small */ > - else if (vcpu->halt_poll_ns < vcpu->kvm->max_halt_poll_ns && > - halt_ns < vcpu->kvm->max_halt_poll_ns) > - grow_halt_poll_ns(vcpu); > + else if (vcpu->halt_poll_ns < max_halt_poll_ns && > + halt_ns < max_halt_poll_ns) > + grow_halt_poll_ns(vcpu, max_halt_poll_ns); > } else { > vcpu->halt_poll_ns = 0; > } > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > . Thanks, Yanan _______________________________________________ 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 9012FC4332F for ; Tue, 15 Nov 2022 03:31:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:CC:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3LjpWFqhzk56/or9gssw/mjmdYwnF11oFC/+8dCT2Qo=; b=BYCRQMSiCBw6LWvnkhFQkfJCoo 5ulYWqLIL2gUGIdUUia5ImWFsefxReVJfUQXo0gE3s/eoxThhdTVY9H5YtIJ2G8cy+xECSEeyYk+8 cCNBiHkxd6WLT07yqaLAyOqE0FodQlCKfhiaMiRBm2u9El/BOyNfovBifhDaVGBPIil+09Xntb42i RvKzoobVkoyHwjc8K0MsSN7xlud7QQqqWjc2GwXchk+Y0l6hEUfVCVK4IvmjQtBVVj7H8X8IQdyg/ OsYCZqqKLZyuD7ZweFjQb9jD/KcY0dJkokHrGF2sFEry8HPinf46xrQoNVVUUhVXAdelaXB5bTMF6 eaUmOP1A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oume8-007Bz7-1f; Tue, 15 Nov 2022 03:30:00 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oumdC-007BW9-R9 for linux-arm-kernel@lists.infradead.org; Tue, 15 Nov 2022 03:29:05 +0000 Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NBBPz29c4zqSHG; Tue, 15 Nov 2022 11:25:11 +0800 (CST) Received: from [10.174.187.128] (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 15 Nov 2022 11:28:56 +0800 Subject: Re: disabling halt polling broken? (was Re: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a new stat) To: Sean Christopherson , Paolo Bonzini CC: Wanpeng Li , kvm , David Hildenbrand , "Kernel Mailing List, Linux" , Paul Mackerras , Claudio Imbrenda , KVM ARM , Janosch Frank , Marc Zyngier , Joerg Roedel , Huacai Chen , Christian Borntraeger , Aleksandar Markovic , Jon Cargille , kvm-ppc , David Matlack , linux-arm-kernel , Jim Mattson , Cornelia Huck , "open list:MIPS" , Vitaly Kuznetsov References: <20210925005528.1145584-1-seanjc@google.com> <03f2f5ab-e809-2ba5-bd98-3393c3b843d2@de.ibm.com> <43e42f5c-9d9f-9e8b-3a61-9a053a818250@de.ibm.com> From: "wangyanan (Y)" Message-ID: <32810c89-44c6-6780-9d05-e49f6b897b6e@huawei.com> Date: Tue, 15 Nov 2022 11:28:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_192903_309795_915BE1FB X-CRM114-Status: GOOD ( 24.58 ) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Sean, Paolo, I recently also notice the behavior change of param halt_poll_ns. Now it loses the ability to: 1) dynamically disable halt polling for all the running VMs by `echo 0 > /sys` 2) dynamically adjust the halt polling interval for all the running VMs by `echo * > /sys` While in our cases, we usually use above two abilities, and KVM_CAP_HALT_POLL is not used yet. On 2021/9/28 1:33, Sean Christopherson wrote: > On Mon, Sep 27, 2021, Paolo Bonzini wrote: >> On Mon, Sep 27, 2021 at 5:17 PM Christian Borntraeger >> wrote: >>>> So I think there are two possibilities that makes sense: >>>> >>>> * track what is using KVM_CAP_HALT_POLL, and make writes to halt_poll_ns follow that >>> what about using halt_poll_ns for those VMs that did not uses KVM_CAP_HALT_POLL and the private number for those that did. >> Yes, that's what I meant. David pointed out that doesn't allow you to >> disable halt polling altogether, but for that you can always ask each >> VM's userspace one by one, or just not use KVM_CAP_HALT_POLL. (Also, I >> don't know about Google's usecase, but mine was actually more about >> using KVM_CAP_HALT_POLL to *disable* halt polling on some VMs!). > I kinda like the idea if special-casing halt_poll_ns=0, e.g. for testing or > in-the-field mitigation if halt-polling is broken. It'd be trivial to support, e.g. Do we have any plan to repost the diff as a fix? I would be very nice that this issue can be solved. Besides, I think we may need some Doc for users to describe how halt_poll_ns works with KVM_CAP_HALT_POLL, like "Documentation/virt/guest-halt-polling.rst". > @@ -3304,19 +3304,23 @@ void kvm_vcpu_halt(struct kvm_vcpu *vcpu) > update_halt_poll_stats(vcpu, start, poll_end, !waited); > > if (halt_poll_allowed) { > + max_halt_poll_ns = vcpu->kvm->max_halt_poll_ns; > + if (!max_halt_poll_ns || !halt_poll_ns) <------ squish the max if halt_poll_ns==0 > + max_halt_poll_ns = halt_poll_ns; > + Does this mean that KVM_CAP_HALT_POLL will not be able to disable halt polling for a VM individually when halt_poll_ns !=0? > if (!vcpu_valid_wakeup(vcpu)) { > shrink_halt_poll_ns(vcpu); > - } else if (vcpu->kvm->max_halt_poll_ns) { > + } else if (max_halt_poll_ns) { > if (halt_ns <= vcpu->halt_poll_ns) > ; > /* we had a long block, shrink polling */ > else if (vcpu->halt_poll_ns && > - halt_ns > vcpu->kvm->max_halt_poll_ns) > + halt_ns > max_halt_poll_ns) > shrink_halt_poll_ns(vcpu); > /* we had a short halt and our poll time is too small */ > - else if (vcpu->halt_poll_ns < vcpu->kvm->max_halt_poll_ns && > - halt_ns < vcpu->kvm->max_halt_poll_ns) > - grow_halt_poll_ns(vcpu); > + else if (vcpu->halt_poll_ns < max_halt_poll_ns && > + halt_ns < max_halt_poll_ns) > + grow_halt_poll_ns(vcpu, max_halt_poll_ns); > } else { > vcpu->halt_poll_ns = 0; > } > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > . Thanks, Yanan _______________________________________________ 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: "wangyanan (Y)" Date: Tue, 15 Nov 2022 03:28:56 +0000 Subject: Re: disabling halt polling broken? (was Re: [PATCH 00/14] KVM: Halt-polling fixes, cleanups and a ne Message-Id: <32810c89-44c6-6780-9d05-e49f6b897b6e@huawei.com> List-Id: References: <20210925005528.1145584-1-seanjc@google.com> <03f2f5ab-e809-2ba5-bd98-3393c3b843d2@de.ibm.com> <43e42f5c-9d9f-9e8b-3a61-9a053a818250@de.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Sean Christopherson , Paolo Bonzini Cc: Wanpeng Li , kvm , David Hildenbrand , "Kernel Mailing List, Linux" , Paul Mackerras , Claudio Imbrenda , KVM ARM , Janosch Frank , Marc Zyngier , Joerg Roedel , Huacai Chen , Christian Borntraeger , Aleksandar Markovic , Jon Cargille , kvm-ppc , David Matlack , linux-arm-kernel , Jim Mattson , Cornelia Huck , "open list:MIPS" , Vitaly Kuznetsov Hi Sean, Paolo, I recently also notice the behavior change of param halt_poll_ns. Now it loses the ability to: 1) dynamically disable halt polling for all the running VMs by `echo 0 > /sys` 2) dynamically adjust the halt polling interval for all the running VMs by `echo * > /sys` While in our cases, we usually use above two abilities, and KVM_CAP_HALT_POLL is not used yet. On 2021/9/28 1:33, Sean Christopherson wrote: > On Mon, Sep 27, 2021, Paolo Bonzini wrote: >> On Mon, Sep 27, 2021 at 5:17 PM Christian Borntraeger >> wrote: >>>> So I think there are two possibilities that makes sense: >>>> >>>> * track what is using KVM_CAP_HALT_POLL, and make writes to halt_poll_ns follow that >>> what about using halt_poll_ns for those VMs that did not uses KVM_CAP_HALT_POLL and the private number for those that did. >> Yes, that's what I meant. David pointed out that doesn't allow you to >> disable halt polling altogether, but for that you can always ask each >> VM's userspace one by one, or just not use KVM_CAP_HALT_POLL. (Also, I >> don't know about Google's usecase, but mine was actually more about >> using KVM_CAP_HALT_POLL to *disable* halt polling on some VMs!). > I kinda like the idea if special-casing halt_poll_ns=0, e.g. for testing or > in-the-field mitigation if halt-polling is broken. It'd be trivial to support, e.g. Do we have any plan to repost the diff as a fix? I would be very nice that this issue can be solved. Besides, I think we may need some Doc for users to describe how halt_poll_ns works with KVM_CAP_HALT_POLL, like "Documentation/virt/guest-halt-polling.rst". > @@ -3304,19 +3304,23 @@ void kvm_vcpu_halt(struct kvm_vcpu *vcpu) > update_halt_poll_stats(vcpu, start, poll_end, !waited); > > if (halt_poll_allowed) { > + max_halt_poll_ns = vcpu->kvm->max_halt_poll_ns; > + if (!max_halt_poll_ns || !halt_poll_ns) <------ squish the max if halt_poll_ns=0 > + max_halt_poll_ns = halt_poll_ns; > + Does this mean that KVM_CAP_HALT_POLL will not be able to disable halt polling for a VM individually when halt_poll_ns !=0? > if (!vcpu_valid_wakeup(vcpu)) { > shrink_halt_poll_ns(vcpu); > - } else if (vcpu->kvm->max_halt_poll_ns) { > + } else if (max_halt_poll_ns) { > if (halt_ns <= vcpu->halt_poll_ns) > ; > /* we had a long block, shrink polling */ > else if (vcpu->halt_poll_ns && > - halt_ns > vcpu->kvm->max_halt_poll_ns) > + halt_ns > max_halt_poll_ns) > shrink_halt_poll_ns(vcpu); > /* we had a short halt and our poll time is too small */ > - else if (vcpu->halt_poll_ns < vcpu->kvm->max_halt_poll_ns && > - halt_ns < vcpu->kvm->max_halt_poll_ns) > - grow_halt_poll_ns(vcpu); > + else if (vcpu->halt_poll_ns < max_halt_poll_ns && > + halt_ns < max_halt_poll_ns) > + grow_halt_poll_ns(vcpu, max_halt_poll_ns); > } else { > vcpu->halt_poll_ns = 0; > } > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > . Thanks, Yanan