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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04ECCC77B7C for ; Wed, 24 May 2023 20:16:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CE56280001; Wed, 24 May 2023 16:16:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57E32900002; Wed, 24 May 2023 16:16:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41EE8280001; Wed, 24 May 2023 16:16:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 328DF900002 for ; Wed, 24 May 2023 16:16:08 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 07F76C0A7C for ; Wed, 24 May 2023 20:16:08 +0000 (UTC) X-FDA: 80826255216.06.534A8B8 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf11.hostedemail.com (Postfix) with ESMTP id 1AF0B4001A for ; Wed, 24 May 2023 20:16:05 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=G2x7cKfO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of 3hXBuZAYKCEo4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3hXBuZAYKCEo4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684959366; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=et28JU3wkykvEfV7tUaeZmOsEZymHIt/E70MuyiU1No=; b=1ePgCN2T/Qn9vQMcOfjXpJsNtGtVkzq7AB6ZHsTnH7FxHonUHScRCGwZ4KTK5P2uu59IAS rSY4ck5Xq9ul4SNMXtk9OAKS/FwwN8pnwHm6ONONA60l8MVIyUZbfW3zste800Ee/ReR2z W5zctnQLM8fY84KqRrwl+ogWP+rJAHU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=G2x7cKfO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of 3hXBuZAYKCEo4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3hXBuZAYKCEo4qmzvos00sxq.o0yxuz69-yyw7mow.03s@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684959366; a=rsa-sha256; cv=none; b=0I4Bo+wV2wqSudr5+sFSRzL4BN9NWzgC+2A7iDaZpd8RLrwnNzVT4uiWzpb5VOQgYbh468 GK6+k+FbYJ6ei1g5VU+k8/1MueXDw0bIq1rd/BHydHCVMMJHPbdrbwv0vL32Q68erlMQLt yUN4Pv4bt5LwJtI65auTBFBPt111Jcs= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-ba81b24c1deso2591166276.3 for ; Wed, 24 May 2023 13:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684959365; x=1687551365; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=et28JU3wkykvEfV7tUaeZmOsEZymHIt/E70MuyiU1No=; b=G2x7cKfO2HsF6MKrRXtuGOoWc4Yj9Z0Q1nyrd66b5CwhWsYKjq6PGytnNGnWnoUbYg 0jM5j8y6re71Mo5bG/5Ojl0FuWMuSP9Eaoaxj5HQpFpkslAfyM1khFmi/TCdIov7pGs1 35dPUO8OrPbZFQbz/PVLHobvQlt75SleU+2ukbo6ZGqKu4GeU1PfbY6dp1LYUPK5l9gh L9G4O1nBLIgKKq1HPdPHhPEBqnrucIszUNCbUVyzwlbALVm3SP6WSm1IH5u9OT/3syhL D/r8JPmU9oz+tOmHzugTg/xI95+Lz3S8lUd5+91fPkwHf4Yn5e/eFKasubnMlzF3zHuL SiTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684959365; x=1687551365; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=et28JU3wkykvEfV7tUaeZmOsEZymHIt/E70MuyiU1No=; b=EiZKCc+qJF0yaUgOM1cAMAprpnBqA7KTMJgcFw5POOL2AcV9oiiM9qqBZ/msYIL3mt 5yvwuCRCeJ2axfuc3cDvsOZ3gUceQxFfE99eiuuKwMyWpCggbm1rKXitxKkVnvKzGN7w LK3DuQT8pQWUig1VAALtHkEVcqPYy506GOdvZ8mJYVMwOB6i9YqGO6t7n9jmaHSHBUxG fMTvSd62qp9NPiqRelWGk9lqPpSC945gg/nlvLj8koWe8Ll4w8+1K32nrLVMfxALEl9E 1jom8BLxZr/qZecZfPdUSYasXqcUdW3LReaH409+bXtMzx8FOOf4y2yhacisYSDH2s8h je7w== X-Gm-Message-State: AC+VfDy2eGGz0Sr3hI5nK9rtU82y5BRJ7WxpWh0VpMfFp05LniilQyWx diyyq5NGqrC4iXG1C13g2VpKPGkUq5s= X-Google-Smtp-Source: ACHHUZ6+sl+l+zuedDR2LRUIRB6sxCHVVBdT9tzV4JiB2otIi8oPUFcdAUNp1gY5P1OZhcp9jKCI0u1SitE= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:ba05:0:b0:ba8:95dd:3ccb with SMTP id t5-20020a25ba05000000b00ba895dd3ccbmr566879ybg.5.1684959365091; Wed, 24 May 2023 13:16:05 -0700 (PDT) Date: Wed, 24 May 2023 13:16:03 -0700 In-Reply-To: Mime-Version: 1.0 References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-9-chao.p.peng@linux.intel.com> Message-ID: Subject: Re: [PATCH v7 08/14] KVM: Rename mmu_notifier_* From: Sean Christopherson To: Kautuk Consul Cc: Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 1AF0B4001A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: jfrmnrhbq8ohooh9gm4dt17bhkwn16p7 X-HE-Tag: 1684959365-768878 X-HE-Meta: U2FsdGVkX18Dy/rxE4AhNzrqj5d8CoN6RDQoPjWfPWHMFyOLAvSDgA2dikACXhkZKwrE26JUgNkmlfiWFB46DyROSihhME41JFnGcz4M1tQ0NKKd2VNGvp16Sm4rh10VVS8k98IE1EUVaIV0GE1PKkVmj/BmRtF2zg0l2mpUWe/1CBAMsVHhO5s0Nt+KRSFXQlYxOGG9xDsbSsgzUuXJfA5YsOeMdmQ8wnflkcrls3Pol4A9cl/HDIxZOS/yE0ppA/9C6yJuzahfdai3stUqTUFBVLUr21jGo2JXENYNr72oJfRr3oS1F9/1zaO6pxGdiAMJx1QdUkQgaNsIRw0TH3xFT/k07Nl2gjERFAboEiWMOtShRmqAhJ0ODv0Npn+53jpqrOH6raXgV8D9SvBXgvcA++ZkaOYPcWwnTZhRRFGPhuBQIZzFE0HVSw31U6FqvLhv4T7Ms7kBqbMHdvZjEYV1VelAIVelSPuTT9g9qBqtReW9XrpFbv0lwZ9sjR0SjRj/GYrBi+WAAtSSsIdDVDgEjT8rnelJPEZI75A9EiaH8K1/x+RLKgakA7GHXl3xAN+0BbZcySrnY8aGkedIPAxK9CEh91dFKkVfWZyP78mIzc0pORhH+K5S6+vmOAySOSFTW3Hdt4mMY8sDvmNN4WBijKZ02pwTz1gKArkl+s16yjr3s6Z8qhs97CZRQIMnvHwYIkpvhoYqlr5lN1RhwQ8wCaXgt8OAf+Oa583k28vEqBLtV20MzKgNWLB2Z45yfX7kdgzoyGmsFKUw02VNPezDhNm56g/nljkpE78/qB0ilM+cbntIY6zlY27zmSCLbsIsH1oCMKYv1JhxKL+VM+SIy/dKBa4IO8dPlOpqsSV0WhJNReydXF5o2NT9YllLdtmpayVAwiVrTIVMstfebPrkiXvCYbOoNX2gfweTsKD1NHu3qa8l0G5Lr1t9E8W9MOz3noez2O2PRyAFJah NyaZbVN+ kxBC3olReImXrhiNJKhytm27wUYQQnY+YwnlLQ4Lk0TJwc4ZyEjwYxqI1+AyZIFUr7TCXlOxUzQiXrhtwA3c2VKv1g31jy0oM8X/Y8G/cUrPBHJyALILyxzrWJHd9AjFEgvKsv3mHK/G4qzyVuUrWqccYGXBVvk88SZaB738WmPI91Gq9PKFn0k2sGK6jh6lguW9914yk90sbmOYWAB49bBsKWNaHA3WMaSrbw5YouIl+3nhsvxHJ/ovJ7Kj2mv6Tu1BlM22kRT18rLTQ5k10KnNcrfum4UfaFQwHrqR3ecim3iz1dHKl6uXeIo1/DzQrFDloa/AjDaMRTUnOpdXLNy5hSR0lRQIhYPLnpphjsyX/IhqRewvPKa+sQJmt/pwb2akU/8Mq92jAQz4++BUQoTot6FXxwV9HbD2jdvTCn4HvP3kCMOs4x5tkQow782mAVe1uhfRJoeYk8jE/yPOdqqJIxm1WQnMEFFRsqZgpNr1ZuqG9FupOLuI2/5R6JV+6EiyoyMDQ8nUY5U4jLt9iqvjs4IkiRY2Qwl2NfEY4ujlnLQIvFfb8RDdIlt2FO/aR3Vw6Nu4Dn3syNmUs0jHlrvDsUfruymuyCBngnU8Ac8iYh7CbC8uQrSYqXWJjvoQSE7kz X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 24, 2023, Kautuk Consul wrote: > On 2023-05-23 07:19:43, Sean Christopherson wrote: > > On Tue, May 23, 2023, Kautuk Consul wrote: > > > On 2022-07-06 16:20:10, Chao Peng wrote: > > > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > > > index e9153b54e2a4..c262ebb168a7 100644 > > > > --- a/include/linux/kvm_host.h > > > > +++ b/include/linux/kvm_host.h > > > > @@ -765,10 +765,10 @@ struct kvm { > > > > > > > > #if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER) > > > > struct mmu_notifier mmu_notifier; > > > > - unsigned long mmu_notifier_seq; > > > > - long mmu_notifier_count; > > > > - gfn_t mmu_notifier_range_start; > > > > - gfn_t mmu_notifier_range_end; > > > > + unsigned long mmu_updating_seq; > > > > + long mmu_updating_count; > > > > > > Can we convert mmu_updating_seq and mmu_updating_count to atomic_t ? > > > > Heh, can we? Yes. Should we? No. > > > > > I see that not all accesses to these are under the kvm->mmu_lock > > > spinlock. > > > > Ya, working as intended. Ignoring gfn_to_pfn_cache for the moment, all accesses > > to mmu_invalidate_in_progress (was mmu_notifier_count / mmu_updating_count above) > > are done under mmu_lock. And for for mmu_notifier_seq (mmu_updating_seq above), > > all writes and some reads are done under mmu_lock. The only reads that are done > > outside of mmu_lock are the initial snapshots of the sequence number. > > > > gfn_to_pfn_cache uses a different locking scheme, the comments in > > mmu_notifier_retry_cache() do a good job explaining the ordering. > > > > > This will also remove the need for putting separate smp_wmb() and > > > smp_rmb() memory barriers while accessing these structure members. > > > > No, the memory barriers aren't there to provide any kind of atomicity. The barriers > > exist to ensure that stores and loads to/from the sequence and invalidate in-progress > > counts are ordered relative to the invalidation (stores to counts) and creation (loads) > > of SPTEs. Making the counts atomic changes nothing because atomic operations don't > > guarantee the necessary ordering. > I'm not saying that the memory barriers provide atomicity. > My comment was based on the assumption that "all atomic operations are > implicit memory barriers". If that assumption is true then we won't need > the memory barriers here if we use atomic operations for protecting > these 2 structure members. Atomics aren't memory barriers on all architectures, e.g. see the various definitions of smp_mb__after_atomic(). Even if atomic operations did provide barriers, using an atomic would be overkill and a net negative. On strongly ordered architectures like x86, memory barriers are just compiler barriers, whereas atomics may be more expensive. Of course, the only accesses outside of mmu_lock are reads, so on x86 that "atomic" access is just a READ_ONCE() load, but that's not the case for all architectures. Anyways, the point is that atomics and memory barriers are different things that serve different purposes.