From: Colton Lewis <coltonlewis@google.com>
To: kvm@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
Colton Lewis <coltonlewis@google.com>
Subject: [PATCH 0/3] Relax break-before-make use with FEAT_BBM
Date: Fri, 2 Jun 2023 17:01:44 +0000 [thread overview]
Message-ID: <20230602170147.1541355-1-coltonlewis@google.com> (raw)
Currently KVM follows the lengthy break-before-make process every time
the page size changes, which requires KVM to do a broadcast TLB
invalidation and data serialization for every affected page table
entry. This is expensive.
FEAT_BBM Level 2 support precludes the need to follow the whole
process when page size is the only thing that changed. This series
detects said support and avoids the unnecessary expensive operations,
speeding up the execution of the stage2 page table walkers.
Considerable time and effort has been spent trying to measure the
performance benefit, mainly using dirty_log_perf_test with huge pages,
but nothing was seen that stood out from ordinary variation between
runs. This is puzzling, but getting the series reviewed anyway may
spark some ideas.
This is based on kvmarm-6.4 + Ricardo's eager page splitting series
[1] to cover the eager splitting case as well. Similar changes were
originally part of that series but it was suggested FEAT_BBM should be
its own series.
[1] https://lore.kernel.org/kvmarm/20230426172330.1439644-1-ricarkol@google.com/
Colton Lewis (2):
KVM: arm64: Clear possible conflict aborts
KVM: arm64: Skip break phase when we have FEAT_BBM level 2
Ricardo Koller (1):
arm64: Add a capability for FEAT_BBM level 2
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/kernel/cpufeature.c | 11 +++++++
arch/arm64/kvm/hyp/pgtable.c | 58 ++++++++++++++++++++++++++++++----
arch/arm64/kvm/mmu.c | 6 ++++
arch/arm64/tools/cpucaps | 1 +
5 files changed, 70 insertions(+), 7 deletions(-)
--
2.41.0.rc0.172.g3f132b7071-goog
next reply other threads:[~2023-06-02 17:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 17:01 Colton Lewis [this message]
2023-06-02 17:01 ` [PATCH 1/3] arm64: Add a capability for FEAT_BBM level 2 Colton Lewis
2023-06-05 15:07 ` Robin Murphy
2023-06-02 17:01 ` [PATCH 2/3] KVM: arm64: Clear possible conflict aborts Colton Lewis
2023-06-09 15:44 ` Oliver Upton
2023-06-02 17:01 ` [PATCH 3/3] KVM: arm64: Skip break phase when we have FEAT_BBM level 2 Colton Lewis
2023-06-04 8:23 ` Marc Zyngier
2023-06-05 21:36 ` Oliver Upton
2023-06-08 17:21 ` Will Deacon
2023-06-09 14:59 ` Oliver Upton
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=20230602170147.1541355-1-coltonlewis@google.com \
--to=coltonlewis@google.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).