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=-11.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no 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 57AC3C43457 for ; Mon, 19 Oct 2020 21:33:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 176A72236F for ; Mon, 19 Oct 2020 21:33:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="XPF+oDHH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733126AbgJSVdS (ORCPT ); Mon, 19 Oct 2020 17:33:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733109AbgJSVdS (ORCPT ); Mon, 19 Oct 2020 17:33:18 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60B24C0613CE for ; Mon, 19 Oct 2020 14:33:18 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id k21so1618701ioa.9 for ; Mon, 19 Oct 2020 14:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mdj1p7VnDdxT5I8Z1qkpE2oOywsVCZLla3gZhFHy3jU=; b=XPF+oDHHW//dsEqICCHUU8aasr8/d2Izf+Yl0wnGj2ZbdcqIvMKiDRfEacCkjCl+dm +x6DymxUcfHs3jkBOwABRrjUj4K1FN/mWgsQQ9sEfOR2gfJE2hdtZ4d5gfTXXsoQW9en sp10cV9D9NqdeVnJv9YnZm2xT4kkNUFHqvuKUq9Fj93qqPb5XmQsqEUo7Oy3MSix6q3I U7X1VpJ1u74ns8HrjDZYIX9ruOvzhILiqP6iYwYqgUVqZGiDyeUQqdgO1o5Af57vqJY8 u2mftXJD+Hb5S3VfhiZF2K6A+xpzfQiUeQN0S1VoLIWyFtPpXy1cIqb6FvVtg04zFMkH P++A== 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=mdj1p7VnDdxT5I8Z1qkpE2oOywsVCZLla3gZhFHy3jU=; b=Ic0QByfXq/KwWGUvNeh1KRlNAXzwtl7qE7DGE0yRQnSkgnxv3HyLZ2FmmBzhn8GrtM FBuZkSLBe5nyiG5ReI+5G3r+rE5gY74nGQsTw3gn20dbGleBuRby9Qhr6iRvD3vKLAE4 ACNVqGGYYhAU3+hgS8mRqLrnApKeZ0wpi0MGxTlzobL7/EkoRp8hexJZEcFwvQpOQvht tV8pPGqDf8vDOZju6zpIA4eMw4QsRi+iuW1AhMYRDNfozwcoMOk261MLfa72fJW8fMbf p25l5jv1BU8WTRYc3rM7Iemue88IkeMoOjpwwFmIFbrnE6P4CEoWGdbst6H8TAhuOnny Yw/w== X-Gm-Message-State: AOAM53147XCVNDmFgiN3R8HRmn9DDzS6d88+aTGKfWL/rWBNNVEonnv9 zCBv7uHfAlhO1HcLl5Jv+ATfTTwRqa4k1BaWTqwYbjwvKxn4J5gg X-Google-Smtp-Source: ABdhPJyIUjmTQziMIJfx7ZRZrfuRE3wJaNY0JSJ+oedy9d8Dxf9Vou6fV3TtI4Va94wdQ7my2Wl19KK18/SEvUH8Uzw= X-Received: by 2002:a02:7817:: with SMTP id p23mr1644891jac.57.1603143197455; Mon, 19 Oct 2020 14:33:17 -0700 (PDT) MIME-Version: 1.0 References: <20201014182700.2888246-1-bgardon@google.com> <20201014182700.2888246-8-bgardon@google.com> In-Reply-To: From: Ben Gardon Date: Mon, 19 Oct 2020 14:33:06 -0700 Message-ID: Subject: Re: [PATCH v2 07/20] kvm: x86/mmu: Support zapping SPTEs in the TDP MMU To: "Edgecombe, Rick P" Cc: "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "kernellwp@gmail.com" , "jmattson@google.com" , "Christopherson, Sean J" , "vkuznets@redhat.com" , "peterx@redhat.com" , "yulei.kernel@gmail.com" , "pshier@google.com" , "pfeiner@google.com" , "cannonmatthews@google.com" , "xiaoguangrong.eric@gmail.com" , "pbonzini@redhat.com" , "junaids@google.com" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Oct 19, 2020 at 1:50 PM Edgecombe, Rick P wrote: > > On Wed, 2020-10-14 at 11:26 -0700, Ben Gardon wrote: > > @@ -5827,6 +5831,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t > > gfn_start, gfn_t gfn_end) > > struct kvm_memslots *slots; > > struct kvm_memory_slot *memslot; > > int i; > > + bool flush; > > > > spin_lock(&kvm->mmu_lock); > > for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) { > > @@ -5846,6 +5851,12 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t > > gfn_start, gfn_t gfn_end) > > } > > } > > > > + if (kvm->arch.tdp_mmu_enabled) { > > + flush = kvm_tdp_mmu_zap_gfn_range(kvm, gfn_start, > > gfn_end); > > + if (flush) > > + kvm_flush_remote_tlbs(kvm); > > + } > > + > > spin_unlock(&kvm->mmu_lock); > > } > > Hi, > > I'm just going through this looking at how I might integrate some other > MMU changes I had been working on. But as long as I am, I'll toss out > an extremely small comment that the "flush" bool seems unnecessary. I agree this could easily be replaced with: if (kvm_tdp_mmu_zap_gfn_range(kvm, gfn_start, gfn_end)) kvm_flush_remote_tlbs(kvm); I like the flush variable just because I think it gives a little more explanation to the code, but I agree both are perfectly good. > > I'm also wondering a bit about this function in general. It seems that > this change adds an extra flush in the nested case, but this operation > already flushed for each memslot in order to facilitate the spin break. > If slot_handle_level_range() took some extra parameters it could maybe > be avoided. Not sure if it's worth it. I agree, there's a lot of room for optimization here to reduce the number of TLB flushes. In this series I have not been too concerned about optimizing performance. I wanted it to be easy to review and to minimize the number of bugs in the code. Future patch series will optimize the TDP MMU and make it actually performant. Two specific changes I have planned to reduce the number of TLB flushes are 1.) a deferred TLB flush scheme using the existing vm-global tlbs_dirty count and 2.) a system for skipping the "legacy MMU" handlers for various operations if the TDP MMU is enabled and the "legacy MMU" has not been used on that VM. I believe both of these are present in the original RFC I sent out a year ago if you're interested. I'll CC you on those future optimizations. > > Rick