From: Zhi Wang <zhi.wang.linux@gmail.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v3 3/6] KVM: x86: Do not unload MMU roots when only toggling CR0.WP
Date: Tue, 7 Feb 2023 15:36:51 +0200 [thread overview]
Message-ID: <20230207153651.000067f8@gmail.com> (raw)
In-Reply-To: <20230201194604.11135-4-minipli@grsecurity.net>
On Wed, 1 Feb 2023 20:46:01 +0100
Mathias Krause <minipli@grsecurity.net> wrote:
> There is no need to unload the MMU roots for a direct MMU role when only
> CR0.WP has changed -- the paging structures are still valid, only the
> permission bitmap needs to be updated.
>
> One heavy user of toggling CR0.WP is grsecurity's KERNEXEC feature to
> implement kernel W^X.
>
Wouldn't it be better to factor out update_permission_bitmask and
update_pkru_bitmask in a common function and call it from here? So that
we can also skip: bunches of if..else..., recalculation of the rsvd mask
and shadow_zero_bit masks.
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.
> The optimization brings a huge performance gain for this case as the
> following micro-benchmark running 'ssdd 10 50000' from rt-tests[1] on a
> grsecurity L1 VM shows (runtime in seconds, lower is better):
>
> legacy TDP shadow
> kvm.git/queue 11.55s 13.91s 75.2s
> kvm.git/queue+patch 7.32s 7.31s 74.6s
>
> For legacy MMU this is ~36% faster, for TTP MMU even ~47% faster. Also
> TDP and legacy MMU now both have around the same runtime which vanishes
> the need to disable TDP MMU for grsecurity.
>
> Shadow MMU sees no measurable difference and is still slow, as expected.
>
> [1] https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Mathias Krause <minipli@grsecurity.net>
> ---
> v2: handle the CR0.WP case directly in kvm_post_set_cr0() and only for
> the direct MMU role -- Sean
>
> I re-ran the benchmark and it's even faster than with my patch, as the
> critical path is now the first one handled and is now inline. Thanks a
> lot for the suggestion, Sean!
>
> arch/x86/kvm/x86.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 508074e47bc0..f09bfc0a3cc1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -902,6 +902,15 @@ EXPORT_SYMBOL_GPL(load_pdptrs);
>
> void kvm_post_set_cr0(struct kvm_vcpu *vcpu, unsigned long old_cr0, unsigned long cr0)
> {
> + /*
> + * Toggling just CR0.WP doesn't invalidate page tables per se, only the
> + * permission bits.
> + */
> + if (vcpu->arch.mmu->root_role.direct && (cr0 ^ old_cr0) == X86_CR0_WP) {
> + kvm_init_mmu(vcpu);
> + return;
> + }
> +
> if ((cr0 ^ old_cr0) & X86_CR0_PG) {
> kvm_clear_async_pf_completion_queue(vcpu);
> kvm_async_pf_hash_reset(vcpu);
next prev parent reply other threads:[~2023-02-07 13:37 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 [this message]
2023-02-08 9:52 ` Mathias Krause
2023-03-15 21:22 ` Sean Christopherson
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=20230207153651.000067f8@gmail.com \
--to=zhi.wang.linux@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minipli@grsecurity.net \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.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.