Re: [RFC PATCH 0/7] arm64: Enable LPA2 support for 16k pages

[Anshuman Khandual <anshuman.khandual@arm.com>]

On 11/18/22 16:20, Ard Biesheuvel wrote:
> On Fri, 18 Nov 2022 at 11:38, Catalin Marinas <catalin.marinas@arm.com> wrote:
>>
>> Hi Ard,
>>
>> On Thu, Nov 17, 2022 at 02:24:16PM +0100, Ard Biesheuvel wrote:
>>> Enable support for LPA2 when running with 16k pages. Unlike with 4k
>>> pages, this does not require adding support for 5 level paging, but
>>> beyond that, there is no fundamental difference between LPA2 support on
>>> 4k or 16k pages.
>>
>> We have some patches already from Anshuman, targeting both 4K and 16K
>> pages:
>>
>> https://lore.kernel.org/r/1632998116-11552-1-git-send-email-anshuman.khandual@arm.com
>>
> 
> Ah right - I was aware that Anshuman had been looking into this as
> well, but I did not realise working code had been sent to the list.
> 
> That series doesn't cover 5 level paging yet, right?

The posted series last year was to enable 52 bit PA for all VA configs on
4K and 16K page sizes. There was a fix (and other changes) to idmap which
enabled two additional idmap levels, to support much spaced VA-PA configs
for FEAT_LPA2, but now those idmap changes need to be reworked after your
recent boot code changes.

But it never enabled 52 bit VA (although I had some local changes) which
would have required proper 5 level paging.

> 
>> I don't think they've been rebased on top of 6.1-rcX though. Could you
>> please liaise with Anshuman and agree on a way forward? I'd rather only
>> review a single series if they do the same thing. I have a preference
>> for a more complete solution (4K and 16K) rather than just 16K pages. I
>> think we can even ignore some corner cases like 39-bit VA (if anyone is
>> asking, we could do it later but it doesn't seem realistic).
>>
> 
> If  we can agree that we don't need more than 48 bits for the ID map
> (at least for the time being), this all fits quite nicely on top of
> the boot code refactor that i sent out last week, where the code in
> head.S is only responsible for creating the [initial] ID map, and
> everything else is done from C code.

I have some changes to 'init_idmap_pg_dir' creation in the assembly code
i.e create_idmap which gets [4K|52PA|48VA] to boot with kernel loaded
beyond 48 bits PA. The problem is, it gets stuck at "smp: Bringing up
secondary CPUs .." as the runtime 'idmap_pg_dir' created with C code
create_idmap() does not handle (does not create required additional
pgtable levels) when VA=48.

Something else I discovered is that current 'idmap_pg_dir' does not work
with an existing config [64K|52PA|48PA] when vmlinux is loaded beyond 48
bits PA. After fixing this existing problem, my plan was to enable it for
FEAT_LPA2 configs on 4K/16K.

> 
> I'll have a look today at how much additional work is needed on top of
> this series to accommodate 4k 52-bit VA and PA support, but beyond
> adding p4d handling in some places, I think it should be fairly
> limited.
> 
>> And a question for Anshuman: do you plan to refresh your series?
>>
> 
> Yeah let's align on a way forward here. Apologies for stepping on
> this, I wasn't aware how much actual code you had already written.

No worries. Let sync up on Monday, or any other time suitable for you.
I can walk you through all that I have, all that planed etc, then we
could figure out how to proceed further.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel