Message ID | 20230316154554.1237-1-shameerali.kolothum.thodi@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp559129wrt; Thu, 16 Mar 2023 08:52:22 -0700 (PDT) X-Google-Smtp-Source: AK7set+7WSd5d8TQdQOFcuHOIF4WmF98I2GZ0FLIoIzKhA7CSbpl5cE4/KPOWru1kojgprCn/dtJ X-Received: by 2002:a17:903:706:b0:19f:188c:3e34 with SMTP id kk6-20020a170903070600b0019f188c3e34mr3539187plb.53.1678981941996; Thu, 16 Mar 2023 08:52:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678981941; cv=none; d=google.com; s=arc-20160816; b=mGm8/OuH924z9f4Z14d37uvbvOQeDqH1y/KS2hg+0VxyDaEesZ4m5DcN9d/tW99JXe 2qj4Xa3lDLmep6eI6G9RliRwRN+7dCcY3lYymJB+TTEWVsFILBJ+wq1h3tS0RNxRXoYl cK5Dga7RTRoSYKbRG23Gv5cg+0kBSJx0XhKovlglnps68jRHnZ5UTB6XiGPT5vZyTTOu B5y6sgf6NSNu6MyYO20eMHWiRMlYF6LxOAeDBjD0cu7mBxd7n3utlAbOeYAcdPQKeWp4 Ov+9DKBaU1CuUq1WrjqgOiHKL/VilZpE1vVy3HjmuJEO1usL/4IDMRpRZyOHV1VehZCB FyqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=qLq2kGVKrRzsVf7E4rw+uswebIEbYT4Z73G7nlfFZH0=; b=VxyYAq2wlzCcwW4/DB6ccxXfp35TU/xYdROLsKbpMSjfBiRnVHT1g5OKOUtMPPMEP8 CZPA5EFi6VimQSBGhppdyMXJu9tAcSNvkqAVmADTeWu7PwRqv78qPVmsbW2zmY3Oej+r MT3uPewJOJ6o6ma1bJvnqKEDj8QIjnk0aQcF4H68MsF3dCQMGi4tdZIaClkXMT0jugiF Rz3qFoy487ifxAjtD/wFPZeYAHmROtXdfyb4UONgAnfpBMuVERNLTw/mnJxkcRtEDfxj quAL9m3KeDDCRjhDgh6O2z05+lYqslw6aYN1eYuiU/IRJHKS2/xlKwRRx1w6BeHzXHbj M+Bw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v3-20020a1709029a0300b0019ca7a76d68si8323590plp.67.2023.03.16.08.52.05; Thu, 16 Mar 2023 08:52:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230304AbjCPPrx (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Thu, 16 Mar 2023 11:47:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230186AbjCPPrv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Mar 2023 11:47:51 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E12E726CD2; Thu, 16 Mar 2023 08:47:22 -0700 (PDT) Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Pcs6C51zQz6J7G1; Thu, 16 Mar 2023 23:45:23 +0800 (CST) Received: from A2006125610.china.huawei.com (10.202.227.178) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Thu, 16 Mar 2023 15:46:18 +0000 From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> To: <linux-kernel@vger.kernel.org>, <kvm@vger.kernel.org> CC: <gshan@redhat.com>, <maz@kernel.org> Subject: [PATCH] KVM: Add the missing stub function for kvm_dirty_ring_check_request() Date: Thu, 16 Mar 2023 15:45:54 +0000 Message-ID: <20230316154554.1237-1-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.202.227.178] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-2.7 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760540168722832078?= X-GMAIL-MSGID: =?utf-8?q?1760540168722832078?= |
Series |
KVM: Add the missing stub function for kvm_dirty_ring_check_request()
|
|
Commit Message
Shameerali Kolothum Thodi
March 16, 2023, 3:45 p.m. UTC
The stub for !CONFIG_HAVE_KVM_DIRTY_RING case is missing.
Fixes: cf87ac739e48 ("KVM: x86: Introduce KVM_REQ_DIRTY_RING_SOFT_FULL")
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
include/linux/kvm_dirty_ring.h | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Thu, Mar 16, 2023, Shameer Kolothum wrote:
> The stub for !CONFIG_HAVE_KVM_DIRTY_RING case is missing.
No stub is needed. kvm_dirty_ring_check_request() isn't called from common code,
and should not (and isn't unless I'm missing something) be called from arch code
unless CONFIG_HAVE_KVM_DIRTY_RING=y.
x86 and arm64 are the only users, and they both select HAVE_KVM_DIRTY_RING
unconditionally when KVM is enabled.
> -----Original Message----- > From: Sean Christopherson [mailto:seanjc@google.com] > Sent: 16 March 2023 17:02 > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> > Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; gshan@redhat.com; > maz@kernel.org > Subject: Re: [PATCH] KVM: Add the missing stub function for > kvm_dirty_ring_check_request() > > On Thu, Mar 16, 2023, Shameer Kolothum wrote: > > The stub for !CONFIG_HAVE_KVM_DIRTY_RING case is missing. > > No stub is needed. kvm_dirty_ring_check_request() isn't called from > common code, > and should not (and isn't unless I'm missing something) be called from arch > code > unless CONFIG_HAVE_KVM_DIRTY_RING=y. > > x86 and arm64 are the only users, and they both select > HAVE_KVM_DIRTY_RING > unconditionally when KVM is enabled. Yes, it is at present not called from anywhere other than x86 and arm64. But I still think since it is a common helper, better to have a stub. Thanks, Shameer
On Thu, Mar 16, 2023, Shameerali Kolothum Thodi wrote: > > From: Sean Christopherson [mailto:seanjc@google.com] > > On Thu, Mar 16, 2023, Shameer Kolothum wrote: > > > The stub for !CONFIG_HAVE_KVM_DIRTY_RING case is missing. > > > > No stub is needed. kvm_dirty_ring_check_request() isn't called from > > common code, > > and should not (and isn't unless I'm missing something) be called from arch > > code > > unless CONFIG_HAVE_KVM_DIRTY_RING=y. > > > > x86 and arm64 are the only users, and they both select > > HAVE_KVM_DIRTY_RING > > unconditionally when KVM is enabled. > > Yes, it is at present not called from anywhere other than x86 and arm64. > But I still think since it is a common helper, better to have a stub. Why? It buys us nothing other than dead code, and even worse it could let a bug that would otherwise be caught during build time escape to run time.
> -----Original Message----- > From: Sean Christopherson [mailto:seanjc@google.com] > Sent: 16 March 2023 19:57 > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> > Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; gshan@redhat.com; > maz@kernel.org > Subject: Re: [PATCH] KVM: Add the missing stub function for > kvm_dirty_ring_check_request() > > On Thu, Mar 16, 2023, Shameerali Kolothum Thodi wrote: > > > From: Sean Christopherson [mailto:seanjc@google.com] On Thu, Mar 16, > > > 2023, Shameer Kolothum wrote: > > > > The stub for !CONFIG_HAVE_KVM_DIRTY_RING case is missing. > > > > > > No stub is needed. kvm_dirty_ring_check_request() isn't called from > > > common code, and should not (and isn't unless I'm missing something) > > > be called from arch code unless CONFIG_HAVE_KVM_DIRTY_RING=y. > > > > > > x86 and arm64 are the only users, and they both select > > > HAVE_KVM_DIRTY_RING unconditionally when KVM is enabled. > > > > Yes, it is at present not called from anywhere other than x86 and arm64. > > But I still think since it is a common helper, better to have a stub. > > Why? It buys us nothing other than dead code, and even worse it could let > a bug that would otherwise be caught during build time escape to run time. Agree, it buys nothing now:) It just came up while I was playing with a custom build without HAVE_KVM_DIRTY_RING. Since all other functions there has a stub just thought it would make it easier for future common usage. We could very well leave it till that comes up as well. Thanks, Shameer
On Thu, Mar 16, 2023, Shameerali Kolothum Thodi wrote: > > From: Sean Christopherson [mailto:seanjc@google.com] > > On Thu, Mar 16, 2023, Shameerali Kolothum Thodi wrote: > > > > From: Sean Christopherson [mailto:seanjc@google.com] On Thu, Mar 16, > > > > 2023, Shameer Kolothum wrote: > > > > > The stub for !CONFIG_HAVE_KVM_DIRTY_RING case is missing. > > > > > > > > No stub is needed. kvm_dirty_ring_check_request() isn't called from > > > > common code, and should not (and isn't unless I'm missing something) > > > > be called from arch code unless CONFIG_HAVE_KVM_DIRTY_RING=y. > > > > > > > > x86 and arm64 are the only users, and they both select > > > > HAVE_KVM_DIRTY_RING unconditionally when KVM is enabled. > > > > > > Yes, it is at present not called from anywhere other than x86 and arm64. > > > But I still think since it is a common helper, better to have a stub. > > > > Why? It buys us nothing other than dead code, and even worse it could let > > a bug that would otherwise be caught during build time escape to run time. > > Agree, it buys nothing now:) It just came up while I was playing with a custom > build without HAVE_KVM_DIRTY_RING. Since all other functions there has a stub > just thought it would make it easier for future common usage. We could very well > leave it till that comes up as well. Stubs are typically only added when they are strictly necessary. Providing a stub would make things "easier" in the sense that it could theoretically avoid a build error, but as above, in many cases we _want_ build errors when new code behaves in a way that diverges from what's expected/established.
diff --git a/include/linux/kvm_dirty_ring.h b/include/linux/kvm_dirty_ring.h index 4862c98d80d3..a00301059da5 100644 --- a/include/linux/kvm_dirty_ring.h +++ b/include/linux/kvm_dirty_ring.h @@ -69,6 +69,11 @@ static inline void kvm_dirty_ring_free(struct kvm_dirty_ring *ring) { } +static inline bool kvm_dirty_ring_check_request(struct kvm_vcpu *vcpu) +{ + return false; +} + #else /* CONFIG_HAVE_KVM_DIRTY_RING */ int kvm_cpu_dirty_log_size(void);