Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5053357ybl; Tue, 4 Feb 2020 06:54:19 -0800 (PST) X-Google-Smtp-Source: APXvYqzrK0Subn3CsrXgbh0yo2aeDHktDKtdlf7m9BOqFdMtY94Faq4bv/K5iZuE1EKq1EpuSK0Q X-Received: by 2002:aca:5582:: with SMTP id j124mr3581091oib.20.1580828059682; Tue, 04 Feb 2020 06:54:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580828059; cv=none; d=google.com; s=arc-20160816; b=0Xqbxewvx9roM8DfNSMn6fl6iAkDvprSv9yX0n6FuRHJBazYFZk4CFGX7VL2mba/NI NeIoF8DD6AQ8v2MhEdaepQgUxKnDK46vBLJB2V0byCgRNKWESc8PBnDNW5zy2SMFfBRr V4rBm47XpOQLP4/RSgAmZf+O28pBe6mzAoFmhR6tl9XGTvipxx2CzOeigtka3ImRDdAp BU0r3pQlqu9YlTCZKmR74sh8/pFxJ1xpIyV6BAnL5buJ3qOAg6ruFoOtI5Gta87Rg0N3 cjYL6gr0P71syCxX9hJQ3WTwvZCDSaRt2bba7h3EcJCFxzQFnyVQkJAfGbywV1NdqgXl VvzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uU8G76jtuHruPjrDW0v61ETIQOe9KIYW3ZvW/roFplk=; b=sVH3ZrdTXYf1OeVQ3ulKjA0LQp62sYY+DBpHO6rSa0DCnnshLqXFid7c8jtBX8c7LU fZ0okJLsJ11zuxllmChW29RrZ4TiBTRQ3SHUcBJrPnmUK2tsrT47DEWs0EcgkaURw2j0 2IU+kZNt5sgyClJdXQh3kAdklKeFUVol65F7xjO+Rq6PGiQfqTLqmgL5g2ginUGSfPwy hSQYyRyZ92N+mxt6FL+hVe2u8XU5yJdIE9FsNd6NETdWalmGeJnzwIhp6W6UYU35kZMU zEg13aeY8S70U5X+GCTla8iGXOa+X9u1ZF5eF93uha1hHMuLGouuOc7Kq5GgY5cfU26B gHmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m12si9998168oim.195.2020.02.04.06.54.07; Tue, 04 Feb 2020 06:54:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727357AbgBDOwO (ORCPT + 99 others); Tue, 4 Feb 2020 09:52:14 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:53835 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727267AbgBDOwN (ORCPT ); Tue, 4 Feb 2020 09:52:13 -0500 Received: from [187.32.88.249] (helo=calabresa) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iyzYe-0002qd-S8; Tue, 04 Feb 2020 14:52:09 +0000 Date: Tue, 4 Feb 2020 11:51:53 -0300 From: Thadeu Lima de Souza Cascardo To: Vitaly Kuznetsov Cc: Wanpeng Li , LKML , kvm , Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel Subject: Re: [PATCH] KVM: Pre-allocate 1 cpumask variable per cpu for both pv tlb and pv ipis Message-ID: <20200204145059.GJ40679@calabresa> References: <878slio6hp.fsf@vitty.brq.redhat.com> <20200204142733.GI40679@calabresa> <871rrao1mr.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871rrao1mr.fsf@vitty.brq.redhat.com> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 04, 2020 at 03:42:04PM +0100, Vitaly Kuznetsov wrote: > Thadeu Lima de Souza Cascardo writes: > > >> > > /* > >> > > @@ -624,6 +625,7 @@ static void __init kvm_guest_init(void) > >> > > kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) { > >> > > pv_ops.mmu.flush_tlb_others = kvm_flush_tlb_others; > >> > > pv_ops.mmu.tlb_remove_table = tlb_remove_table; > >> > > + pr_info("KVM setup pv remote TLB flush\n"); > >> > > } > >> > > > > > > I am more concerned about printing the "KVM setup pv remote TLB flush" message, > > not only when KVM pv is used, but pv TLB flush is not going to be used, but > > also when the system is not even paravirtualized. > > Huh? In Wanpeng's patch this print is under > > if (kvm_para_has_feature(KVM_FEATURE_PV_TLB_FLUSH) && > !kvm_para_has_hint(KVM_HINTS_REALTIME) && > kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) > > and if you mean another patch we descussed before which was adding > (!kvm_para_available() || nopv) check than it's still needed. Or, > alternatively, we can make kvm_para_has_feature() check for that. > > -- > Vitaly > Yes, that's what I mean. Though not printing that when allocating the cpumasks would fix this particular symptom, anyway. But yes, it doesn't make sense to do all those feature checks when there is no paravirtualization. I believe we are in agreement. Cascardo.