Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3795800ybl; Mon, 3 Feb 2020 06:42:40 -0800 (PST) X-Google-Smtp-Source: APXvYqwsbIiww/V++7I6jmdClZgVwOG34gQ2Qm8jUW/TNK+tWImcii4eWTiLDtv0kZxwz/ioesUj X-Received: by 2002:a05:6808:902:: with SMTP id w2mr7646832oih.170.1580740960525; Mon, 03 Feb 2020 06:42:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580740960; cv=none; d=google.com; s=arc-20160816; b=L/TKnnmVaa1/NPrNaTX85QDF6F77uoY/oVlRhsDflDrjltESGZREC6cij7iIzRJGmp SII9lYAvrxBk/aeE9qb3EjZbdNt4gBQeIzrNU5Fci0rgxt4UgCTTB84Hseia+UPKvy+1 u10Zxc9e4YihMdzkduY9SFJemXsgzR7fXiwC7Dy0OcM7TYvq8QcbdoNo2cUluAkCCE1E eqNeDXn9MEjJb7SQxdowacvD4Yiid1W8Rb7REVJphIcamxL3c6DALA//ND/noetHTF7I 1yN5QIGM/vZPGDsDbzpH42UDHdW/p9s6IOmggix329u40PzYR9zvkDxpwy4x199qk4es iTZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=FTCmDQysPO2gEhLvRlu7l+eCldmNVtgMTfK/8SOuiPM=; b=i+Ss/vrBMNJOfOmSufrmpjAG+SFtayeSWH1TXU28X6UuRh3PLCNNe7klBo4udteJVS OloPqNYGJE2p7mx3MCqieXG3nPbSnPuuEDEvLSFoa8JdY43DClP/DQTUImi9N5IwOdBj pQ7tYUXEg4mRZ7ZtS5mf+rQqzKXDfAhvhhi0rQ+A9l9KiBfb0zjqMQihCYFeYW/78MSM /Mgi+DyfGwCwRdcxTt183kHQIb70HxBTwukcjo07XDejqcN/lSLcZA+PiXugzi2fHYY3 AxeYM71ZtsmY4WREZLtK5Dyy1nsj+RhMxka1atWw128KYZoQocdASz0FfBcecSuw4MqH Xhlw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nDKbYV6u; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t22si4892922oth.211.2020.02.03.06.42.27; Mon, 03 Feb 2020 06:42:39 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nDKbYV6u; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728111AbgBCM0G (ORCPT + 99 others); Mon, 3 Feb 2020 07:26:06 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:44465 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727942AbgBCM0F (ORCPT ); Mon, 3 Feb 2020 07:26:05 -0500 Received: by mail-ot1-f67.google.com with SMTP id h9so13373704otj.11; Mon, 03 Feb 2020 04:26:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FTCmDQysPO2gEhLvRlu7l+eCldmNVtgMTfK/8SOuiPM=; b=nDKbYV6uLewDDeqqtQtLza9EvsovQ7dTpZoqlikdkjx+2dGD7U9IgOCA53Zt8jkjaW B9335Rfk4p0quSJrTdgyNQBT8EtMnu9xPRwi99FO9QyAQuHgQlQChej3yMsYrkaiEjiG mnaD39diqcN1X6vzeRZBB7NOnZGfwkQqHmpw3UUWPnvUab+9IOqhp2bUvV2QyA/kjRO7 QFFf35i7+dEJXW++VqEanbYTun9GkBbtPY9ABt7fgljTImboi3KtRwbEENoRdQ61Mm/h I/c55CZ1poNhc26OU0x+oFq9P3o+oYSsZ5cZVsgD862BiaHoZiVYg45LsmdF2Cc8OqYB 37gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FTCmDQysPO2gEhLvRlu7l+eCldmNVtgMTfK/8SOuiPM=; b=HUFlFUNY09PGvcSDTr5Q9/hhrPd2QvFaDo8LJri+7szZHnKYHXbH/5BLJbR4moH+bz FBDVSrTU4Cy9Px4eCQKtuVGNTuSziKozIufc7CGvqf9s+CQOAaJ+WPy1Cbrti9l/TG9N +i2VucUQzUVMuZhvFU6ATXUY/96iWEeHWl2F581Fzcbyo8oJ7FI4wOUmmkOg4Cq6cDyI /2d0N23CZblLjkYjm2MFkUZof5yftKBvuz5+M4ZRotamI9NHBuC9i4Yzv+RSULulv7cW p6mAVAJ/xpkV1p2ru3Zw6UKve7kr8smwkyC/5jBzSvAUo3rRKVkS+9BMhP3ON2uuX8P2 Nung== X-Gm-Message-State: APjAAAV1Y0HMFsQ7kEqza7a5Fo4H4Tt35AXlYFINDZQXnQkZ6Hqrof7H /6p8WOtMPOC//xIs3uHQI1ossYPw/sO+XyMLcpU= X-Received: by 2002:a05:6830:1:: with SMTP id c1mr16142470otp.254.1580732764862; Mon, 03 Feb 2020 04:26:04 -0800 (PST) MIME-Version: 1.0 References: <20200131155655.49812-1-cascardo@canonical.com> <87wo94ng9d.fsf@vitty.brq.redhat.com> <20200203101514.GG40679@calabresa> In-Reply-To: <20200203101514.GG40679@calabresa> From: Wanpeng Li Date: Mon, 3 Feb 2020 20:25:53 +0800 Message-ID: Subject: Re: [PATCH] x86/kvm: do not setup pv tlb flush when not paravirtualized To: Thadeu Lima de Souza Cascardo Cc: Vitaly Kuznetsov , Paolo Bonzini , Sean Christopherson , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , LKML , kvm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Feb 2020 at 18:31, Thadeu Lima de Souza Cascardo wrote: > > On Mon, Feb 03, 2020 at 10:59:10AM +0100, Vitaly Kuznetsov wrote: > > Thadeu Lima de Souza Cascardo writes: > > > > > kvm_setup_pv_tlb_flush will waste memory and print a misguiding message > > > when KVM paravirtualization is not available. > > > > > > Intel SDM says that the when cpuid is used with EAX higher than the > > > maximum supported value for basic of extended function, the data for the > > > highest supported basic function will be returned. > > > > > > So, in some systems, kvm_arch_para_features will return bogus data, > > > causing kvm_setup_pv_tlb_flush to detect support for pv tlb flush. > > > > > > Testing for kvm_para_available will work as it checks for the hypervisor > > > signature. > > > > > > Besides, when the "nopv" command line parameter is used, it should not > > > continue as well, as kvm_guest_init will no be called in that case. > > > > > > Signed-off-by: Thadeu Lima de Souza Cascardo > > > --- > > > arch/x86/kernel/kvm.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c > > > index 81045aabb6f4..d817f255aed8 100644 > > > --- a/arch/x86/kernel/kvm.c > > > +++ b/arch/x86/kernel/kvm.c > > > @@ -736,6 +736,9 @@ static __init int kvm_setup_pv_tlb_flush(void) > > > { > > > int cpu; > > > > > > + if (!kvm_para_available() || nopv) > > > + return 0; > > > + > > > 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)) { > > > > The patch will fix the immediate issue, but why kvm_setup_pv_tlb_flush() > > is just an arch_initcall() which will be executed regardless of the fact > > if we are running on KVM or not? > > > > In Hyper-V we setup PV TLB flush from ms_hyperv_init_platform() -- which > > only happens if Hyper-V platform was detected. Why don't we do it from > > kvm_init_platform() in KVM? > > > > -- > > Vitaly > > > > Because we can't call the allocator that early. > > Also, see the thread where this was "decided", the v6 of the original patch: > > https://lore.kernel.org/kvm/20171129162118.GA10661@flask/ A little change to this function. https://lore.kernel.org/kvm/CANRm+CwK0Cg45mktda9Yz9fsjPCvtuB8O+fma5L3tV725ki1qw@mail.gmail.com Testing is a great appreciated. (Still in vacation) Wanpeng