Re: [PATCH 00/22] KVM: arm64: nv: Implement FEAT_HAFDBS, FEAT_HAFT

[Leonardo Bras <leo.bras@arm.com>]

On Fri, Jun 26, 2026 at 06:12:21PM +0100, Marc Zyngier wrote:
> On Fri, 26 Jun 2026 16:31:50 +0100,
> Leonardo Bras <leo.bras@arm.com> wrote:
> > 
> > On Tue, Jun 23, 2026 at 11:41:39AM -0700, Oliver Upton wrote:
> > > KVM's support for hardware descriptor updates has been lacking, owing in
> > > large part to the fact that the most widely available NV2 hardware
> > > actually lacks HAFDBS :)
> > > 
> > > This series brings support for hardware dirty state and table Access
> > > flags to the nested MMU. While KVM uses neither of these features, the
> > > kernel definitely does in the stage-1 page tables. Since there is only
> > > one hypervisor to rule them all, implementing this stuff at stage-2 is
> > > mostly motivated by the desire to enable guest stage-1 :)
> > > 
> > > Implementing dirty state at stage-2 is a bit more challenging than
> > > anticipated, I'm in the middle of seeking a relaxation from Arm that
> > > would make this all architectural. See the last patch for the details.
> > 
> > Hi Oliver,
> > 
> > Haven't read your patchset yet, but in regards to stage-2 dirty-state
> > tracking, there have already been some efforts in the area, also
> > implementing HDBSS and HACDBS in a way of improving performance / reducing 
> > impact of live migration on a system.
> 
> I'm worried you are reading this series the wrong way. This is mostly
> orthogonal to the whole HDBSS/HACDBS/SLAUA (Super Long And
> Unpronounceable Acronym). Oh wait, you haven't read it yet. Great :-(.

Sorry, I have very little understanding of nested, and I wrongly thought 
this patchset would be in some way also involve hw-accelerated dirty-bit 
usage.


> 
> This series is about *implementing* HAFDBS and HAFT in NV. We can't
> rely on the HW setting the AF and DB in the guest's own S2 PTs,
> because these page tables are never live. So we have to do it
> ourselves.

Got it!

> 
> So this has nothing to do with S2 dirty tracking for the purpose of
> migration. The guest could implement its own migration based on that,
> but that has nothing to do with what this series is doing.
> 


Makes sense.

Thanks for clarifying this, and for your patience.
Leo