All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: Leonardo Bras <leo.bras@arm.com>
Cc: 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>,
	Tian Zheng <zhengtian10@huawei.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/3] Set DBM bit on writable pages
Date: Mon, 26 Oct 2026 12:08:59 -0700	[thread overview]
Message-ID: <at-lSy7H-K60LhCB@kernel.org> (raw)
In-Reply-To: <20261026144413.441566-1-leo.bras@arm.com>

On Mon, Oct 26, 2026 at 02:44:06PM +0000, Leonardo Bras wrote:
> When HAFDBS is enabled (VTCR_EL2.{HA,HD}={1,1}), having a DBM bit allows 
> hardware to promote a non-writable page to writable by setting (S2AP[1]=1),
> without having to take a fault.
> 
> The reason for this patchset is to add the DBM bit when setting-up writable 
> pages, so the code is prepared for future patches that make use of 
> HDBSS/HACDBS to accelerate dirty-tracking. Write-bit detection still 
> happens based only in S2AP[1], so no change in that aspect.
> 
> Having DBM set on block entries is undesired, as we benefit from the first 
> fault for splitting it in PAGE_SIZE entries, which is the granularity used 
> to track the dirty pages in KVM. So introduce a new walker that, on top of 
> clearing S2AP[1] for every entry, also clear DBM for block entries.
> 
> Also introduce a new VCPU request to reload Stage2, as it will be needed on 
> future HDBSS/HAFDBS patchsets. 
> 
> Please let me know of what do you think!

I'm pretty sure I shared this feedback before, but patches that enable
DBM do not make sense in isolation. We need a single series that
contains the DBM enablement as well as the corresponding HDBSS support.

> Changes since RFCv1:
> - Dropped patch #5 on enabling HAFDBS on non-dirty-tracking guests, as it 
>   proved to be counter-productive on wrprotect, contrary to expectations
> - No more moving writable-bit to DBM. That does not seem to be the intended 
>   use. It makes sense and it's easier to convert code to new DBM approach.

Sorry, where was this concluded?

The abstract permission flags need to have a WRITE an DIRTY state, which
we then map to hardware based on the capabilities of the system.

!FEAT_HAFDBS:

	DIRTY	=> S2AP[1]
	WRITE	=> S2AP[1]

FEAT_HAFDBS:

	DIRTY	=> S2AP[1]
	WRITE	=> DBM

Beyond making the whole HAFDBS easy to reason about, I want this for
FEAT_S2PIE which reimagines bit 7 as a literal dirty bit that can be
managed by software or hardware.

Thanks,
Oliver

  parent reply	other threads:[~2026-10-26 19:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26 14:44 [RFC PATCH v2 0/3] Set DBM bit on writable pages Leonardo Bras
2026-10-26 14:44 ` [RFC PATCH v2 1/3] KVM: arm64: pgtables: Set DBM attribute on writable Stage-2 PTEs Leonardo Bras
2026-10-26 14:44 ` [RFC PATCH v2 2/3] KVM: arm64: Introduce a dedicated walker for stage2 write-protect Leonardo Bras
2026-10-26 14:44 ` [RFC PATCH v2 3/3] KVM: arm64: Add KVM_REQ_RELOAD_STAGE2 Leonardo Bras
2026-10-26 19:08 ` Oliver Upton [this message]
2026-10-27 11:44   ` [RFC PATCH v2 0/3] Set DBM bit on writable pages Leonardo Bras
2026-10-27 11:48     ` Leonardo Bras
2026-10-27 23:19     ` Oliver Upton
2026-10-29 18:20       ` 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=at-lSy7H-K60LhCB@kernel.org \
    --to=oupton@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=fuad.tabba@linux.dev \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=leo.bras@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@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.