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

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

On Tue, Jan 24, 2023 at 09:48:28AM -0800, David Matlack wrote:
> 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:

[...]

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

That could work, so long as the respective ISAs don't depend on any
specific numbering scheme. For arm64 the level hints encoded in TLBIs
match our numbering scheme, which is quite valuable. We are definitely
at odds with RISC-V's numbering scheme (descending order, starting from
root), but AFAICT there doesn't appear to be any portion of the ISA that
depends on it (yet).

Sure, we could add some glue code to transform KVM's common leveling
scheme into an architecture-specific one for these use cases, but I
worry that'll be incredibly error-prone.

In any case I'd prefer we not make any changes at this point, as they'd
be purely cosmetic.

--
Thanks,
Oliver