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@xxxxxxxxx> 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.
