From: Sean Christopherson <seanjc@google.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: Zhi Wang <zhi.wang.linux@gmail.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v3 3/6] KVM: x86: Do not unload MMU roots when only toggling CR0.WP
Date: Wed, 15 Mar 2023 14:22:10 -0700 [thread overview]
Message-ID: <ZBI3AtIvMXEK3Csc@google.com> (raw)
In-Reply-To: <0ac184a7-4325-a1f7-b533-41a7e590c66c@grsecurity.net>
On Wed, Feb 08, 2023, Mathias Krause wrote:
> On 07.02.23 14:36, Zhi Wang wrote:
> > On Wed, 1 Feb 2023 20:46:01 +0100
> > Mathias Krause <minipli@grsecurity.net> wrote:
> > I suppose this is a critical path according to the patch comments and
> > kvm_init_mmu() is a non-critical path. Is it better to seperate
> > them now for saving the maintanence efforts in future? E.g. something heavier
> > might be introduced into the kvm_init_mmu() path and slows down this path.
>
> I'll look into what can be done about it. But this change is a first
> step that can be further optimized via follow up changes.
>
> As you can see from the numbers below, it's already way faster that what
> we have right now, so I'd rather land this (imperfect) change sooner
> than later and gradually improve on it. This will, however, likely only
> bring minor speedups compared to this change, so they're less important,
> IMHO.
>
> The question is really what's better from a maintenance point of view:
> Keeping the call to the commonly used kvm_init_mmu() function or special
> case even further? I fear the latter might regress easier, but YMMV, of
> course.
Agreed. Unless the performance benefits of getting super precise are significant,
I would much rather keep things simpler and reduce the risk of introducing bugs.
Bugs in this area in particular have a nasty habit of being really good at hiding.
next prev parent reply other threads:[~2023-03-15 21:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 19:45 [PATCH v3 0/6] KVM: MMU: performance tweaks for heavy CR0.WP users Mathias Krause
2023-02-01 19:45 ` [PATCH v3 1/6] KVM: x86/mmu: Avoid indirect call for get_cr3 Mathias Krause
2023-02-01 19:46 ` [PATCH v3 2/6] KVM: VMX: Avoid retpoline call for control register caused exits Mathias Krause
2023-03-15 21:38 ` Sean Christopherson
2023-03-20 20:43 ` Mathias Krause
2023-02-01 19:46 ` [PATCH v3 3/6] KVM: x86: Do not unload MMU roots when only toggling CR0.WP Mathias Krause
2023-02-07 13:36 ` Zhi Wang
2023-02-08 9:52 ` Mathias Krause
2023-03-15 21:22 ` Sean Christopherson [this message]
2023-03-15 22:11 ` Sean Christopherson
2023-03-20 21:13 ` Mathias Krause
2023-02-01 19:46 ` [PATCH v3 4/6] KVM: x86: Make use of kvm_read_cr*_bits() when testing bits Mathias Krause
2023-02-07 13:05 ` Zhi Wang
2023-02-08 9:11 ` Mathias Krause
2023-02-14 11:08 ` Zhi Wang
2023-03-15 22:18 ` Sean Christopherson
2023-03-20 21:34 ` Mathias Krause
2023-03-21 15:57 ` Sean Christopherson
2023-02-01 19:46 ` [PATCH v3 5/6] KVM: x86/mmu: Fix comment typo Mathias Krause
2023-02-01 19:46 ` [PATCH v3 6/6] KVM: VMX: Make CR0.WP a guest owned bit Mathias Krause
2023-03-15 22:30 ` Sean Christopherson
2023-03-20 21:31 ` Mathias Krause
2023-03-06 6:34 ` [PATCH v3 0/6] KVM: MMU: performance tweaks for heavy CR0.WP users Mathias Krause
2023-03-06 18:07 ` 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=ZBI3AtIvMXEK3Csc@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minipli@grsecurity.net \
--cc=pbonzini@redhat.com \
--cc=zhi.wang.linux@gmail.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.