Received: by 2002:ac2:48a3:0:0:0:0:0 with SMTP id u3csp26977lfg; Tue, 8 Mar 2022 18:28:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJyCa4zIU5RqYOQqjOiVMNlq7o+opL0UyS8rRmqnfwdQ40n64/rXVf6BH24F3FXVI79tnUnR X-Received: by 2002:a17:90a:578f:b0:1bc:7122:f7f0 with SMTP id g15-20020a17090a578f00b001bc7122f7f0mr7990239pji.209.1646792920271; Tue, 08 Mar 2022 18:28:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646792920; cv=none; d=google.com; s=arc-20160816; b=UoT12/V3VyNbEhJsfoX+8tok4Cu9gLGg+B4xTvbCOAWt+kuv/HFHCU8nu6hckaOaCC uq8ws4hZvvCZJbkdfdIzv2TNgS62PWkJ/Brt7OhcDTVmZ8oKBndy24BYGMYMC8wc1i6s vm09hfeLZGqeArLmTSHQxtFSjXht2pfDnjSXKK1WFnoz2bNWmE/d7zseEEyZv5CWEswn POkIlu0zg+GDEGQUIrEGrMt/JHpmGuCXu+Q3LEdut25nDGgUOgYzIGEbd5V0b1FUOHjf UkHErLjF22fySl0d3MU3iiKiBX1cuNxEswSFypL16R3OxFRj+6rKwu4aaftaRZfGWjTj oMdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=O0sfGtZZs/DCXFYwja5rvdRYEUrfDeT/e0HTIIylfkg=; b=BPc+cQWfJOSlV/Xu0TqrYinjTpYUfLYFLBnHDHBVgqiCclb07SmTU3sKUCItaFvfLI dI5RBkAHoOaeV46x3rHRWmkanXB012waLYFfD+m+OJ6+xpS7s9YF75tI5fkdTL2TxJcm d7+Q/DgxsaCjVaM5LAR85fL92IwlJUp+uFjb3zFqAyrpvA4epn/2lHVDJA37LqGaY1Eo V92Y/P5qQrHKDhXk8FTsIxhA37OZj6rpTpiZz8gBbfW1VB5RrWcg29kpKLAdWXUf9ryt yyZ7UjQHR+R0hUF079XMzWX1GvyyqYr8Q5hvL5Pv2llky98NX0wmdpzAfsmENYeOWTJ3 SI9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=l4rVX7J5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id bg14-20020a056a02010e00b00372eacfe8ddsi575318pgb.879.2022.03.08.18.28.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 18:28:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=l4rVX7J5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F3B8DBABB9; Tue, 8 Mar 2022 17:37:08 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230306AbiCIBiE (ORCPT + 99 others); Tue, 8 Mar 2022 20:38:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231153AbiCIBiB (ORCPT ); Tue, 8 Mar 2022 20:38:01 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAE10BABB9; Tue, 8 Mar 2022 17:37:01 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id g1so1371090ybe.4; Tue, 08 Mar 2022 17:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O0sfGtZZs/DCXFYwja5rvdRYEUrfDeT/e0HTIIylfkg=; b=l4rVX7J5aBaez9SIxbPd0e7Jjd3gHLMAN0Wc6zzGVSMOeK42ZvHs4Bc6lPiS3ZUbcP UGfCmxnSojCAZ7N33msSaTo1U/B3GcMw/aU5OW1WbFaHZV4Kfqz8d5pj05HQ6p1mlBKy pP18JcugAEvOPH3EYM6mjWtlQlZQUiR/CY9JQLvd5d5h/vE916blcoH3puN20a64FRTo moYha8UiaO0SM4KXzK+aIJQtJ6e4dm+iQTFrrPDmBI5c+Aai4QH42R3nEqYGo7JjxQp1 dt1vhyW91fdU0yaxlC5qTRgj9jwdMqXPjqcyheLeIWhTRaLL2dnFYqm6ZjyElb2KEfg+ 0mVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O0sfGtZZs/DCXFYwja5rvdRYEUrfDeT/e0HTIIylfkg=; b=vq00slQHt/ogoQgrtUVrJgQEwUeyyEua9Ptk51LhGQbi3l2vyknoaPTyw7xUadJ170 t+MgdyknYSbi91Bz2Nv10q/7gCu7gZGsy4aT+NSmOz+aCPz/ya8fePaTJbi6aEJOwEBv 4NP+K6kEA6/BXiRrVb203i7GlSYS9qo8B/Ba3uV8AFISZCQdmLsPvgAh3stOQs+tPypy mpub7g+1fyl8SE4Ahz17RrAIJ/FG+rcTuki97wmpucxsekNbm7vv1U8W0Wn3YfP2cYc3 fZVTUM4AcHXUZBqog5fKmSguSGawKQamEwabFQ4QjcCNsTJTzXOwbIHTWMpg37GMU1Gl FMxA== X-Gm-Message-State: AOAM531lcvJqSseyAE3TJtAca5m63iUz0QBG+5H4h42B4DUB4Iigxa9W MJp6ypD+jUsyA6CuMzkMo1xvAn9EvP6g5eTy1xo= X-Received: by 2002:a25:1b45:0:b0:628:833c:f3af with SMTP id b66-20020a251b45000000b00628833cf3afmr14352135ybb.138.1646789821221; Tue, 08 Mar 2022 17:37:01 -0800 (PST) MIME-Version: 1.0 References: <1646727529-11774-1-git-send-email-wanpengli@tencent.com> <6e57aad6-1322-8a3d-6dfa-ff010a61a9a9@redhat.com> In-Reply-To: <6e57aad6-1322-8a3d-6dfa-ff010a61a9a9@redhat.com> From: Wanpeng Li Date: Wed, 9 Mar 2022 09:36:50 +0800 Message-ID: Subject: Re: [PATCH] x86/kvm: Don't waste kvmclock memory if there is nopv parameter To: Paolo Bonzini Cc: LKML , kvm , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Mar 2022 at 20:13, Paolo Bonzini wrote: > > On 3/8/22 09:18, Wanpeng Li wrote: > > From: Wanpeng Li > > > > When the "nopv" command line parameter is used, it should not waste > > memory for kvmclock. > > > > Signed-off-by: Wanpeng Li > > --- > > arch/x86/kernel/kvmclock.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > > index c5caa73..16333ba 100644 > > --- a/arch/x86/kernel/kvmclock.c > > +++ b/arch/x86/kernel/kvmclock.c > > @@ -239,7 +239,7 @@ static void __init kvmclock_init_mem(void) > > > > static int __init kvm_setup_vsyscall_timeinfo(void) > > { > > - if (!kvm_para_available() || !kvmclock) > > + if (!kvm_para_available() || !kvmclock || nopv) > > return 0; > > > > kvmclock_init_mem(); > > Perhaps instead !kvm_para_available() && nopv should clear the kvmclock > variable? Do you mean if (!kvm_para_available() && nopv) return 0? I misunderstand why they are the same. :) Wanpeng