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

[Oliver Upton <oupton@kernel.org>]

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 :-(.
> 
> 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.
> 
> 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.

Sorry, I haven't looked at the HDBSS/HACDBS stuff yet. Just want to be
clear, neither of these features make sense for the host to use in the
context of NV.

KVM's dirty tracking is done on the L1 IPA space, however nested MMUs
translate the L2 IPA space. The descriptors emitted by HDBSS would be of
the L2 IPA space and would require reverse-translation for each entry...

Software dirty tracking is the way to go for nested MMUs. Maybe in the
distant future we can emulate HDBSS/HACDBS for the L1 hypervisor. Maybe.

Thanks,
Oliver