Re: RFC KVM: arm64: selftest: stage 2 mapping helpers

[Oliver Upton <oliver.upton@linux.dev>]

On Wed, Oct 22, 2025 at 04:57:16PM +0000, Yosry Ahmed wrote:
> On Wed, Oct 22, 2025 at 06:34:58AM -0700, Sean Christopherson wrote:
> > +Yosry and Jim
> > 
> > On Mon, Oct 20, 2025, Oliver Upton wrote:
> > > > +void virt_arch_s2_map(struct kvm_vm *vm, u64 ipa, u64 paddr);
> > > > +
> > > > +static inline void virt_s2_map(struct kvm_vm *vm, u64 ipa, u64 paddr)
> > > > +{
> > > > +	virt_arch_s2_map(vm, ipa, paddr);
> > > > +}
> > > 
> > > This is all going to be arm64-specific, no need for indirection through
> > > something pretending to be arch-generic.
> > 
> > I was going to ask about that.  Do we want to try and provide a generic interface?

The problem is it isn't just page tables. It's the whole nested CPU
context, hypervisor trap configuration, and means of entering/exiting
the guest (i.e. ERET & exception entry vs. VMRUN).

I'm not fundamentally opposed to trying to do nested in common tests,
but I'd like to have a rough idea of how all the necessary parts will
fit together.

> > Yosry (and Jim) are working on unifying as much of the AMD vs. Intel logic as
> > possible, and if my wishes come true, unifying stage-1 and stage-2 mapping code
> > as well.
> 
> Your wishes already came true:
> https://lore.kernel.org/kvm/20251021074736.1324328-1-yosry.ahmed@linux.dev/.
> 
> For x86, the patches reuse most of the stage-1 mapping code for stage-2,
> with the only exception being using a different sets of bitmaks.
> 
> We end up with a nested_map() API (and some friends) for creating
> stage-2 mappings for L1 (by L0). I imagine we can make that an
> arch-agnostic interface.
> 
> A cooler thing (but probably far-fetched) thing to do is to reuse
> virt_pg_map() in nested_map() in the arch-agnostic code. Example, each
> arch provides bitmasks and other stuff, and then the generic code calls
> virt_map() (and friends) directly.
> 
> The feasibility depends on how similar stage-2 page tables are between
> archs, and how much differences would need to be conveyed to virt_map().

One of the other things for arm64 right now is enabling the 'common'
tests seems less interesting than doing low level testing on our nested
MMU implementation. That probably means we're going to deviate quite a
bit from virt_map() (e.g. using a different translation granule than
vm->page_size)

IOW, the starting point for us is fine-grained control over potentially
multiple stage-2 MMUs with modal descriptor fields that change meaning
based on the current MMU context.

> > I.e. if we envision any arch-agnositic tests that can do nested things,
> > now's the time.  E.g. running dirty logging tests in L2 maybe?

We can just as easily implement an agnostic wrapper after the fact;
enabling architectural validation of the arm64 nested implementation is
the highest priority at the moment for us.

Thanks,
Oliver