From: Leonardo Bras <leo.bras@arm.com>
To: Tian Zheng <zhengtian10@huawei.com>
Cc: Leonardo Bras <leo.bras@arm.com>,
liuyonglong <liuyonglong@huawei.com>,
Oliver Upton <oupton@kernel.org>, Marc Zyngier <maz@kernel.org>,
Fuad Tabba <fuad.tabba@linux.dev>,
Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Raghavendra Rao Ananta <rananta@google.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 5/5] KVM: arm64: Enable HAFDBS for guests not on migration
Date: Thu, 29 Oct 2026 11:54:49 +0000 [thread overview]
Message-ID: <auM0CWJTPzYUTknh@LeoBrasDK> (raw)
In-Reply-To: <52945586-8c5c-4991-bd92-fe02aaf79fbe@huawei.com>
On Thu, Oct 29, 2026 at 10:54:24AM +0800, Tian Zheng wrote:
> Hi Leo,
>
> I've read your discussion with Oliver on DBM RFC v2. As a suggestion,
> maybe we should go with Oliver's approach, i.e. revert to the v1 scheme
> and continue fixing from there.
Hi Tian,
I have been reading a bit more about permission indirection to try figuring
out a way that the change may work for both ways.
The problem with the previous approach is that it assume DBM=write at all
times, which is not architecturally correct. Having DBM=write only on
HAFDBS=on as suggested would require us to transverse the whole pagetable
to convert encodings when we enable/disable it, which can be quite
expensive.
One option would be to always enable HAFDBS when system supports HDBSS, but
I still have to figure out if that causes any performance regression before
suggesting.
The option I am pursuing is thinking on an unified code path for direct
permissison (both HACDBS=on and HACDBS=off) so we don't have to convert
between them, neither worry about the impact of HAFDBS=on on performance.
I will reply on the thread once I figure one of those options out.
Thanks!
Leo
next prev parent reply other threads:[~2026-10-29 11:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 17:15 [RFC PATCH 0/5] KVM: arm64: New PTE dirty-page encoding, HAFDBS new usage Leonardo Bras
2026-09-01 17:15 ` [RFC PATCH 1/5] KVM: arm64: pgtables: Change write bit from S2AP_W to DBM Leonardo Bras
2026-09-01 17:30 ` sashiko-bot
2026-09-02 11:07 ` Leonardo Bras
2026-09-13 9:00 ` Marc Zyngier
2026-09-15 17:12 ` Leonardo Bras
2026-09-16 0:37 ` Oliver Upton
2026-09-16 11:22 ` Leonardo Bras
2026-09-16 12:20 ` Marc Zyngier
2026-09-16 13:25 ` Leonardo Bras
2026-09-18 11:43 ` Tian Zheng
2026-09-18 9:39 ` Tian Zheng
2026-09-21 14:15 ` Leonardo Bras
2026-09-29 10:30 ` Tian Zheng
2026-09-16 8:30 ` Marc Zyngier
2026-09-16 13:03 ` Leonardo Bras
2026-09-01 17:15 ` [RFC PATCH 2/5] KVM: arm64: Add KVM_PGTABLE_PROT_DIRTY Leonardo Bras
2026-09-01 17:34 ` sashiko-bot
2026-09-02 11:30 ` Leonardo Bras
2026-09-13 9:09 ` Marc Zyngier
2026-09-15 17:33 ` Leonardo Bras
2026-09-01 17:15 ` [RFC PATCH 3/5] KVM: arm64: Introduce a dedicated walker for stage2 write-protect Leonardo Bras
2026-09-01 17:15 ` [RFC PATCH 4/5] KVM: arm64: Add KVM_REQ_RELOAD_STAGE2 Leonardo Bras
2026-09-02 3:41 ` Tian Zheng
2026-09-02 10:53 ` Leonardo Bras
2026-09-01 17:15 ` [RFC PATCH 5/5] KVM: arm64: Enable HAFDBS for guests not on migration Leonardo Bras
2026-09-01 17:49 ` sashiko-bot
2026-09-02 13:16 ` Leonardo Bras
2026-09-16 0:10 ` Oliver Upton
2026-09-16 14:00 ` Leonardo Bras
2026-09-16 23:27 ` Oliver Upton
2026-09-17 13:40 ` Leonardo Bras
2026-10-14 15:56 ` Leonardo Bras
2026-10-23 7:23 ` Tian Zheng
2026-10-23 12:01 ` Leonardo Bras
2026-10-27 2:02 ` Tian Zheng
2026-10-27 11:46 ` Leonardo Bras
2026-10-29 2:54 ` Tian Zheng
2026-10-29 11:54 ` Leonardo Bras [this message]
2026-09-18 11:58 ` Tian Zheng
2026-09-21 14:28 ` Leonardo Bras
2026-09-29 11:30 ` Tian Zheng
2026-09-12 12:24 ` [RFC PATCH 0/5] KVM: arm64: New PTE dirty-page encoding, HAFDBS new usage Marc Zyngier
2026-09-15 15:31 ` Leonardo Bras
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=auM0CWJTPzYUTknh@LeoBrasDK \
--to=leo.bras@arm.com \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyonglong@huawei.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=rananta@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
--cc=zhengtian10@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 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.