From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C837FC4707F for ; Thu, 27 May 2021 19:28:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A8A8D613DD for ; Thu, 27 May 2021 19:28:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235109AbhE0TaK (ORCPT ); Thu, 27 May 2021 15:30:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229764AbhE0TaI (ORCPT ); Thu, 27 May 2021 15:30:08 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 383CCC061760 for ; Thu, 27 May 2021 12:28:34 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id d16so1337338pfn.12 for ; Thu, 27 May 2021 12:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/O5ZhuBU+E+S9yjOSjBJ2tbmDg0k5UnIlNPV88NbNt8=; b=LoaeLRZlDL3Zq3Zd/tewzbdTcRqd2FoIe2Ud3xVPjrou4mOgWkVGVhVv+yi2Etdq0C JmvQQYY24N5EwBAXiJxrehqSo7HmuxfEDwPgstNdh3QYHUmI53WoTnYGS36k877OfA+1 saZWbIYrWK66PHlsX4RrzOiuMpPD5Oga7jHWPBI9zhOsxTAEVKF9Q3xkH700R4xEAMf4 LBzjyqSkXjZfiriZXMgYeVAqg9AIJO754AwePcmLCuIb570ChLM5GaUbJ1iiE9TER7aF pCUezaNaivUZjPQJZlHlxFq6U/X0ENbEWroeJllH3T9JRGR5A7rBheWeMGaSD8HENDr8 4Msw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=/O5ZhuBU+E+S9yjOSjBJ2tbmDg0k5UnIlNPV88NbNt8=; b=quI0XTK8wXbhn3cSkv4EZ7/Ew5aWqRgeUq9/GN7f8QCS1BY67+RuUiwU34UqKPes2h /YiVpFUFfW4a08YSR3vBw+7OrcQ75i0b9Aoh0q0WjadoD98ooEe4FSdBBFqN1euqRZP1 8SZKFVCtlv8whvDeNPK31yr3l/DvGMMkt4db9IjWUdaIOwWyV7RiT74BKXRjZuYaWuro y2pIIJW7+kFzgh0pUiMxU9569EnvWdnImjezng16g77vslaIISP8jCvWH7A2SE2YEaXK bPkj+7VDIMvimsKMwauTNZGB1EFLfsGVV9x5bpQ5LZIpgDE1KXS2WR0bX96jEJKJaj1H Ob3g== X-Gm-Message-State: AOAM531/qk1OCE9n+KMyX+mT4VdB+axWvqDLtvfT/AgRmP/+FGrQMGmg mEScVbgP8kcycr2ViaIEfyqKNdtELvO23g== X-Google-Smtp-Source: ABdhPJyxUO8wraNuT3RiXmkpiKZMNkAonQRla5oCtqEG/+FP940vF05hrfXq1ETZufBsWncVy5pwEw== X-Received: by 2002:a05:6a00:88b:b029:2de:33b3:76c9 with SMTP id q11-20020a056a00088bb02902de33b376c9mr24401pfj.30.1622143713551; Thu, 27 May 2021 12:28:33 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id r4sm2404750pff.197.2021.05.27.12.28.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 May 2021 12:28:32 -0700 (PDT) Date: Thu, 27 May 2021 19:28:29 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, Lai Jiangshan , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Maxim Levitsky , kvm@vger.kernel.org Subject: Re: [PATCH] KVM: X86: fix tlb_flush_guest() Message-ID: References: <20210527023922.2017-1-jiangshanlai@gmail.com> <78ad9dff-9a20-c17f-cd8f-931090834133@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 27, 2021, Sean Christopherson wrote: > > KVM_REQ_MMU_RELOAD is overkill, nuking the shadow page tables will completely > > offset the performance gains of the paravirtualized flush. Argh, I take that back. The PV KVM_VCPU_FLUSH_TLB flag doesn't distinguish between flushing a specific mm and flushing the entire TLB. The HyperV usage (via KVM_REQ) also throws everything into a single bucket. A full RELOAD still isn't necessary as KVM just needs to sync all roots, not blast them away. For previous roots, KVM doesn't have a mechanism to defer the sync, so the immediate fix will need to unload those roots. And looking at KVM's other flows, __kvm_mmu_new_pgd() and kvm_set_cr3() are also broken with respect to previous roots. E.g. if the guest does a MOV CR3 that flushes the entire TLB, followed by a MOV CR3 with PCID_NOFLUSH=1, KVM will fail to sync the MMU on the second flush even though the guest can technically rely on the first MOV CR3 to have synchronized any previous changes relative to the fisrt MOV CR3. Lai, if it's ok with you, I'll massage this patch as discussed and fold it into a larger series to fix the other bugs and do additional cleanup/improvements. > > I believe the minimal fix is: > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 81ab3b8f22e5..b0072063f9bf 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -3072,6 +3072,9 @@ static void kvm_vcpu_flush_tlb_all(struct kvm_vcpu *vcpu) > > static void kvm_vcpu_flush_tlb_guest(struct kvm_vcpu *vcpu) > > { > > ++vcpu->stat.tlb_flush; > > + > > + if (!tdp_enabled) > > + kvm_mmu_sync_roots(vcpu); > > static_call(kvm_x86_tlb_flush_guest)(vcpu); > > }