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=-13.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,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 BBA20C433ED for ; Tue, 4 May 2021 17:26:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A32C61176 for ; Tue, 4 May 2021 17:26:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231250AbhEDR1R (ORCPT ); Tue, 4 May 2021 13:27:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231258AbhEDR1O (ORCPT ); Tue, 4 May 2021 13:27:14 -0400 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3D38C06174A for ; Tue, 4 May 2021 10:26:16 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id t4so14447982ejo.0 for ; Tue, 04 May 2021 10:26:16 -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=rxPQs6Mc/0XgO0iPTxIWTDm1QwB91U+obNxE6TB3puk=; b=HSqaJrWOLagPy9VeCugMJRSqJH/RCVf4WnZv8AGdSA/g/g8gJ4ddCdfqzdjQpho/ep b+g8nDxDr5nXus+K6ZPidzG7zFFn2sJFMHfUXAUcv+BLUryxfHKI66wRKJmV6+2Ts51w QE1KVgsIh/P+qQ2Vo2nC20cGmK6aVvqR9Y6yATf6CoFsVM1OvxZNmgi6ULvdqtN2OQG3 /a76ijrzglhwkrHfPINjg55fMOMvudZ4zQP3dBmhK6EveROGh+E2yp269tA0LgtbQW9C mqyfjPeQ2xfoMslqTTUQh191C7CHc0I7RYji2/7JgiFxTWnvfZI0zcOsAHqwrkl793rX E9Iw== 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=rxPQs6Mc/0XgO0iPTxIWTDm1QwB91U+obNxE6TB3puk=; b=AaYyVVJIHrqsha1YHZxeLQ97SB/YGijv/FnzVouCYmMIqpDK/JkJEGllshm38MNJih XEogJKcFG5YalFLsEsspxSTDxHjG2E0OlLl2YitLd9PaYzA9uPPEvqOFVZEQEwLEonqc MrJ1kUG6zbRN+MhD5S0uLIFMXYa6WM9UK/ymIHPvMaetrrydq791B1+2VFd6Mw+QbWZi 4aSKH36qondk15BKzm3SIuYqu2lNjl3VUOGBCJFyHdfKDDfP6I2p3vyLyHWME/Bsn/+/ FpIxJHljiIEs2qoQ4/MzauQ8/w1JzwhOUiLtxg8S/lHch5Dfq2MnqgCBMxU/V8KHXSgu bcDA== X-Gm-Message-State: AOAM533RaI4210K4/x9z5AmTA0JSalCUdwSHREl+Om/ypn+H6tbg2jN4 gNq/MaSJ0Q7wJhwZyM9YDvJeLQoEF/fOfrng7PjqPw== X-Google-Smtp-Source: ABdhPJyFNCokH6hoCachY2WucnKHo93RfBLcmZHm+pw764hTXNO5Lz696SFDbY3yUhOyP+Y3MBPIAfDivYvaBqO83Vo= X-Received: by 2002:a17:906:11d4:: with SMTP id o20mr23126097eja.247.1620149175224; Tue, 04 May 2021 10:26:15 -0700 (PDT) MIME-Version: 1.0 References: <20210429211833.3361994-1-bgardon@google.com> <20210429211833.3361994-2-bgardon@google.com> In-Reply-To: From: Ben Gardon Date: Tue, 4 May 2021 10:26:03 -0700 Message-ID: Subject: Re: [PATCH v2 1/7] KVM: x86/mmu: Track if shadow MMU active To: Paolo Bonzini Cc: LKML , kvm , Peter Xu , Sean Christopherson , Peter Shier , Junaid Shahid , Jim Mattson , Yulei Zhang , Wanpeng Li , Vitaly Kuznetsov , Xiao Guangrong Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 3, 2021 at 6:42 AM Paolo Bonzini wrote: > > On 29/04/21 23:18, Ben Gardon wrote: > > +void activate_shadow_mmu(struct kvm *kvm) > > +{ > > + kvm->arch.shadow_mmu_active = true; > > +} > > + > > I think there's no lock protecting both the write and the read side. > Therefore this should be an smp_store_release, and all checks in > patch 2 should be an smp_load_acquire. That makes sense. > > Also, the assignments to slot->arch.rmap in patch 4 (alloc_memslot_rmap) > should be an rcu_assign_pointer, while __gfn_to_rmap must be changed like so: > > + struct kvm_rmap_head *head; > ... > - return &slot->arch.rmap[level - PG_LEVEL_4K][idx]; > + head = srcu_dereference(slot->arch.rmap[level - PG_LEVEL_4K], &kvm->srcu, > + lockdep_is_held(&kvm->slots_arch_lock)); > + return &head[idx]; I'm not sure I fully understand why this becomes necessary after patch 4. Isn't it already needed since the memslots are protected by RCU? Or is there already a higher level rcu dereference? __kvm_memslots already does an srcu dereference, so is there a path where we aren't getting the slots from that function where this is needed? I wouldn't say that the rmaps are protected by RCU in any way that separate from the memslots. > > Paolo >