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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85670C433EF for ; Fri, 4 Mar 2022 18:42:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241798AbiCDSnR (ORCPT ); Fri, 4 Mar 2022 13:43:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241802AbiCDSmy (ORCPT ); Fri, 4 Mar 2022 13:42:54 -0500 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 533C81D5290 for ; Fri, 4 Mar 2022 10:42:06 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id i1so8541511plr.2 for ; Fri, 04 Mar 2022 10:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=cs84OhdNH2h7DgkARusgjaWFEIKoZx5AjRkQCrMC5j8=; b=aGTrtWvd6UH8YtfZkGtNoARnSHTSDh4UY4tZDZNvJMlmEFkJYxhIcvMXqACOkW0g1v 1IokoBvPvg16zTC1EsWQaK+oPkEZcjs15eO6NagRnYaVHPN8pSbmatDwCZ6NX+IfEUYI 633XmQx2WpExkByBWzDqXNqhTOohAnUEf8FkhEM2veK2S3XCqK7C4IBSzeRxiHMuRi6U d7smNDELCqEQ/gyS3qlGj43skkygkHgB27Xs2NKpq/gHyGBvdhGl/A4nRKeWFSHwkePh E5jHjvbR8YxqwmNHmeukyR2qTz9arG2DhfVCc2i3MPzI0DumhvZxGR2kXeZZiGdITy8I OIfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cs84OhdNH2h7DgkARusgjaWFEIKoZx5AjRkQCrMC5j8=; b=dB9w6mrlLNlbFKutqb9l9tS/wKnW1Vc4Ty6ODH7VOeIKT7WAucne5ccqHtP0sCr9k7 uld8hm9G2ZFJzKczNZdF622USCOH8S7NB6BgyfnO8x8FK4U1AGxaT1NhJuaf0rehPXp4 BSDBWNpvnziEQAcIUQCAtYNrh1xrXN3WSIeDYl8mpQ102pxhs8ByoQ5GcOm5Go7l5Zbl ufbyjVRosllRf12TVdiS2yp+kMmh+wwAa8Gl6hfF3eIlv2VnZ8aT07/iM5eTaOOQXFpk enO/RQV6dCyp76jrmCUWbPu4dvduSHDTvLIG16hmrMEdxOr2q23TJrQHWlF0iXEmxygF YX7A== X-Gm-Message-State: AOAM530EFW7ZMtXIHQESZhu/sFHOV1qyJo0juACDs8CnbtfApIsOPFPB RUNoXmwMRhk7Zsikj1kLToUj8A== X-Google-Smtp-Source: ABdhPJzUsAIKeeCKEhl8wC2iesiNcUfoqK1dobXEn8en9HwCN6ybgeB4VDiXEXBij2JMHDjc3am+xA== X-Received: by 2002:a17:902:da91:b0:151:8e79:8307 with SMTP id j17-20020a170902da9100b001518e798307mr17407834plx.8.1646419325660; Fri, 04 Mar 2022 10:42:05 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id mu1-20020a17090b388100b001bedddf2000sm5471903pjb.14.2022.03.04.10.42.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Mar 2022 10:42:04 -0800 (PST) Date: Fri, 4 Mar 2022 18:42:01 +0000 From: Sean Christopherson To: Mingwei Zhang Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , David Hildenbrand , David Matlack , Ben Gardon Subject: Re: [PATCH v4 18/30] KVM: x86/mmu: Zap only TDP MMU leafs in kvm_zap_gfn_range() Message-ID: References: <20220303193842.370645-1-pbonzini@redhat.com> <20220303193842.370645-19-pbonzini@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 Fri, Mar 04, 2022, Mingwei Zhang wrote: > On Fri, Mar 04, 2022, Sean Christopherson wrote: > > On Fri, Mar 04, 2022, Mingwei Zhang wrote: > > > On Thu, Mar 03, 2022, Paolo Bonzini wrote: > > > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c > > > > index f3939ce4a115..c71debdbc732 100644 > > > > --- a/arch/x86/kvm/mmu/tdp_mmu.c > > > > +++ b/arch/x86/kvm/mmu/tdp_mmu.c > > > > @@ -834,10 +834,8 @@ bool kvm_tdp_mmu_zap_sp(struct kvm *kvm, struct kvm_mmu_page *sp) > > > > } > > > > > > > > /* > > > > - * Tears down the mappings for the range of gfns, [start, end), and frees the > > > > - * non-root pages mapping GFNs strictly within that range. Returns true if > > > > - * SPTEs have been cleared and a TLB flush is needed before releasing the > > > > - * MMU lock. > > > > + * Zap leafs SPTEs for the range of gfns, [start, end). Returns true if SPTEs > > > > + * have been cleared and a TLB flush is needed before releasing the MMU lock. > > > > > > I think the original code does not _over_ zapping. But the new version > > > does. > > > > No, the new version doesn't overzap. > > It does overzap, but it does not matter and the semantic does not > change. Belaboring the point a bit... it very much matters, KVM must "overzap" for functional correctness. It's only an "overzap" from the perspective that KVM could thoeretically shatter the hugepage then zap only the relevant small pages. But it's not an overzap in the sense that KVM absolutely has to zap the hugepage. Even if KVM replaces it with a shadow page, the hugepage is still being zapped, i.e. it's gone and KVM must do a TLB flush regardless of whether or not there's a new mapping.