From: Sean Christopherson <seanjc@google.com>
To: Mingwei Zhang <mizhang@google.com>
Cc: Jim Mattson <jmattson@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Ben Gardon <bgardon@google.com>
Subject: Re: [PATCH] KVM: x86/mmu: Remove KVM MMU write lock when accessing indirect_shadow_pages
Date: Tue, 6 Jun 2023 17:28:24 -0700 [thread overview]
Message-ID: <ZH/PKMmWWgJQdcJQ@google.com> (raw)
In-Reply-To: <CAL715WJ1rHS9ORR2ttyAw+idqbaLnOhLveUhW8f4tB9o+ZsuiQ@mail.gmail.com>
On Tue, Jun 06, 2023, Mingwei Zhang wrote:
> > > Hmm. I agree with both points above, but below, the change seems too
> > > heavyweight. smp_wb() is a mfence(), i.e., serializing all
> > > loads/stores before the instruction. Doing that for every shadow page
> > > 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 runtime
barrier.
next prev parent reply other threads:[~2023-06-07 0:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-05 0:43 [PATCH] KVM: x86/mmu: Remove KVM MMU write lock when accessing indirect_shadow_pages Mingwei Zhang
2023-06-05 16:55 ` Jim Mattson
2023-06-05 17:17 ` Ben Gardon
2023-06-05 17:53 ` Mingwei Zhang
2023-06-05 18:27 ` Paolo Bonzini
2023-06-05 17:42 ` Mingwei Zhang
2023-06-05 18:11 ` Jim Mattson
2023-06-05 18:23 ` Mingwei Zhang
2023-06-05 18:25 ` Sean Christopherson
2023-06-06 22:46 ` Mingwei Zhang
2023-06-06 22:48 ` Mingwei Zhang
2023-06-06 23:07 ` Sean Christopherson
2023-06-07 0:23 ` Mingwei Zhang
2023-06-07 0:28 ` Sean Christopherson [this message]
2023-06-15 23:57 ` Mingwei Zhang
2023-06-26 17:38 ` Jim Mattson
2023-06-26 20:42 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZH/PKMmWWgJQdcJQ@google.com \
--to=seanjc@google.com \
--cc=bgardon@google.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.