Re: [PATCH 3/9] KVM: arm64: Add kvm_pgtable_stage2_split()

[David Matlack <dmatlack@google.com>]

On Tue, Jan 24, 2023 at 09:18:33AM -0800, Ricardo Koller wrote:
> On Tue, Jan 24, 2023 at 9:11 AM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Tue, Jan 24, 2023 at 08:46:58AM -0800, Ricardo Koller wrote:
> > > On Mon, Jan 23, 2023 at 05:03:23PM -0800, Ben Gardon wrote:
> >
> > [...]
> >
> > > > Would it be accurate to say:
> > > > /* No huge pages can exist at the root level, so there's nothing to
> > > > split here. */
> > > >
> > > > I think of "last level" as the lowest/leaf/4k level but
> > > > KVM_PGTABLE_MAX_LEVELS - 1 is 3?
> > >
> > > Right, this is the 4k level.
> > >
> > > > Does ARM do the level numbering in
> > > > reverse order to x86?
> > >
> > > Yes, it does. Interesting, x86 does
> > >
> > >       iter->level--;
> > >
> > > while arm does:
> > >
> > >       ret = __kvm_pgtable_walk(data, mm_ops, childp, level + 1);
> > >
> > > I don't think this numbering scheme is encoded anywhere in the PTEs, so
> > > either architecture could use the other.
> >
> > The numbering we use in the page table walkers is deliberate, as it
> > directly matches the Arm ARM. While we can certainly use either scheme
> > I'd prefer we keep aligned with the architecture.
> 
> hehe, I was actually subtly suggesting our x86 friends to change their side.

Yeah KVM/x86 and KVM/ARM use basically opposite numbering schemes for
page table levels.

Level | KVM/ARM | KVM/x86
----- | ------- | ---------------
pte   | 3       | 1 (PG_LEVEL_4K)
pmd   | 2       | 2 (PG_LEVEL_2M)
pud   | 1       | 3 (PG_LEVEL_1G)
p4d   | 0       | 4
      | -1      | 5

The ARM levels come from the architecture, whereas the x86 levels are
arbitrary.

I do think it would be valuable to standardize on one leveling scheme at
some point. Otherwise, mixing level schemes is bound to be a source of
bugs if and when we are sharing more MMU code across architectures.