Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1858885rwd; Thu, 15 Jun 2023 17:19:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5O6oWciqxzuEtSAxSq+qVZ1Tu4LluAylegLW9U296VnXsTOqbQxK7E3I507+KZE6Ew4so2 X-Received: by 2002:a05:6830:e8e:b0:6b0:66f5:2817 with SMTP id dp14-20020a0568300e8e00b006b066f52817mr599774otb.34.1686874760793; Thu, 15 Jun 2023 17:19:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686874760; cv=none; d=google.com; s=arc-20160816; b=D85vI6uR3XN4CmgmnJWbuZh+owEWLRcaAtagwTBYJ2m/oTsxlHywH4+XYbd6pj+SbB 0z5iLEv0bEWsbbWJbqXmWN4Vnyxtc4sVGWbB6+PMXqsQeTMMvvKwcrRuUEva8AdUwuwN CaDv+u12fBfXygS1yPA1oshl0lrU/sdm4VGhjQX7dFRUsryeZ9qCJ+y1AI8d6HORuReR gkT8RQvO390p20xEl6iLqEEEYqGQxZPzy3A19AB36tQoSABydgZiVBLOLGqNdk4mfKav kHxio4r+Uf5XUiNVIwHlxoF5hcK8EL2W/CQ6P5TWtvzBOOlSwUWWmD6ZjQgyngXjfarr IBuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=hsldixVoPkFu+sgLKcb7381mh1dpFejnHhZ3xNKtZcQ=; b=ZPqJ5M+sOAAv0VokY7tf/gKABxbA5w8wv1SGgeQW8oehl++8k/Xgpu3H/nsLWujWd3 5FrBb4sQ7mLLQ8BHy9WkYQvWZ2SIPLBPBAyiWWoyVgjc/xZB5lM7RH70f0Go4rAnlLKK ttD/unJfo15mu35EgToSXeyGojFpAE3XPAalVTcSGuvQgQdSHX73tSNp62wuLSYAeAXO OJo0jYgL/wxasq05zpbHhlxsYqoHSO7M5DbDSy9f+MtHKn4wlJ+O0RdSGdnh1oqJTiyn NKKYSiXW5roaQo//elJZqHsfoOm1a5V0eeGbLdB+mjSVHELu6NPUcCq86IqejG8CXrfF kYOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=n8PCX3kX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 24-20020a631258000000b00543c8ad57f3si13295528pgs.82.2023.06.15.17.19.07; Thu, 15 Jun 2023 17:19:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=n8PCX3kX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240422AbjFOX6O (ORCPT + 99 others); Thu, 15 Jun 2023 19:58:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231195AbjFOX6M (ORCPT ); Thu, 15 Jun 2023 19:58:12 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD6442707 for ; Thu, 15 Jun 2023 16:58:11 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-514ab6cb529so2699775a12.1 for ; Thu, 15 Jun 2023 16:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686873489; x=1689465489; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=hsldixVoPkFu+sgLKcb7381mh1dpFejnHhZ3xNKtZcQ=; b=n8PCX3kXLm6H3l19sc/u529LfXwDjnAMgO68h3K/w/KEVnoo2OZfWBgb6laG/bCtRL neTMaBJYJf27dn4xIYGy+ng9pm68btbX2cb1tYHZWGm9vPckpg6xBKXJxnnaT4ZBfZ+F EGH5/TyGK7p1BPW6tl5thLq8OVyuZVHqUIbxGVo3XZuBHsXljMaqlU399ZER4oUlZsNM 6L8VmVaiDmE3hFzH0NyPZ/srVlTcYtimcF5KQEFOptm1eotB575wYPLKCMDaBg97Kc8a KT/a5C5wVzXQbi6XJzsv+AQDBy6rtnnPtU2HId4htWaBvu0I64qnH5il6eE0gITBDtg7 mhog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686873489; x=1689465489; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hsldixVoPkFu+sgLKcb7381mh1dpFejnHhZ3xNKtZcQ=; b=iXMeMxSGYBsSmOQ2/Vw14QTvfLkXxN7KGd6Oxql6GhpGWkMIG3YO4o7RestzzpWyKw g+OwHPScpAWUT6UINF3ohyI/MflETR78kXEAKQu80Pjnpm91K66oxsDHznyFlhpmPIqk CSaEj2VapRjKyks7glGCuiCNGLXiQGCr3FDmwEhsiulbtUlpS4GygAbYo8Cwour797G0 YvN1HxjIFlsMC5gwhRUUudoWv3lGyFHpwLAHwt3/gUXbwXAtXDMRqKc8nkiLqMKjSDwz kCfMmzmkN90fJpSW3WZF6S1x8NmPjijSGH4smwlN/e1qTkIVtY+B5zHha4Y7pDNzM46l bbwA== X-Gm-Message-State: AC+VfDyMaQ5lj8jJbAfvstxQv8fy3pa8jj64ZL3eEbSi3aU6p45V4zjV symKLws5nlda6O9URILXsD+LSicXl4Eq24MAec3eGfmK5VD3MFn/7x4= X-Received: by 2002:a17:907:802:b0:974:fb94:8067 with SMTP id wv2-20020a170907080200b00974fb948067mr6126517ejb.23.1686873489622; Thu, 15 Jun 2023 16:58:09 -0700 (PDT) MIME-Version: 1.0 References: <20230605004334.1930091-1-mizhang@google.com> In-Reply-To: From: Mingwei Zhang Date: Thu, 15 Jun 2023 16:57:33 -0700 Message-ID: Subject: Re: [PATCH] KVM: x86/mmu: Remove KVM MMU write lock when accessing indirect_shadow_pages To: Sean Christopherson Cc: Jim Mattson , Paolo Bonzini , "H. Peter Anvin" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Gardon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 6, 2023 at 5:28=E2=80=AFPM Sean Christopherson wrote: > > On Tue, Jun 06, 2023, Mingwei Zhang wrote: > > > > Hmm. I agree with both points above, but below, the change seems to= o > > > > heavyweight. smp_wb() is a mfence(), i.e., serializing all > > > > loads/stores before the instruction. Doing that for every shadow pa= ge > > > > creation and destruction seems a lot. > > > > > > No, the smp_*b() variants are just compiler barriers on x86. > > > > hmm, it is a "lock addl" now for smp_mb(). Check this: 450cbdd0125c > > ("locking/x86: Use LOCK ADD for smp_mb() instead of MFENCE") > > > > So this means smp_mb() is not a free lunch and we need to be a little > > bit careful. > > Oh, those sneaky macros. x86 #defines __smp_mb(), not the outer helper. = I'll > take a closer look before posting to see if there's a way to avoid the ru= ntime > barrier. Checked again, I think using smp_wmb() and smp_rmb() should be fine as those are just compiler barriers. We don't need a full barrier here. Thanks. -Mingwei