| 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);