[RFC PATCH 0/2] arm64: Add support for 48-bit Physical Addresses

Radha Mohan mohun106 at gmail.com
Thu Dec 5 09:35:52 EST 2013


On Thu, Nov 28, 2013 at 7:44 AM, Radha Mohan <mohun106 at gmail.com> wrote:
> On Wed, Nov 27, 2013 at 11:29 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 27/11/13 15:33, Radha Mohan wrote:
>>> On Wed, Nov 27, 2013 at 4:34 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> [CC-ing the maintainers - seems odd they were not cc-ed the first place]
>>>>
>>>> On 27/11/13 07:34, mohun106 at gmail.com wrote:
>>>>> From: Radha Mohan Chintakuntla <rchintakuntla at cavium.com>
>>>>>
>>>>> This patch series provides an implementation of supporting 48-bit
>>>>> Physical Addresses for ARMv8 platforms. It is the maximum width that
>>>>> any ARMv8 based processor can support.
>>>>>
>>>>> The implementation extends the existing support of 40-bit PA.The kernel
>>>>> and user space will now be able to access 128TB each. With 4KB page size
>>>>> the Linux now will be using 4 levels of page tables by making use of
>>>>> 'pud'. And with 64KB page size the Linux will be using 3 levels of page
>>>>> tables.
>>>>>
>>>>> The code has been tested with LTP.
>>>>
>>>> Aside from finding out whether or not this is a useful change, this
>>>> breaks KVM, more specifically the way kernel pages are mapped into HYP.
>>>> Also, guests will still be limited to 40-bit IPAs, and the stage-2
>>>> output range needs to be addressed as well.
>>>
>>> This is useful for platforms (like ours) that will use 48-bit PAs.
>>> Sooner or later there will
>>> be such processors.
>>
>> So should the 4-level page table cost be unconditionally forced onto all
>> implementations?
>>
>
> We can have a kernel compile-time config option so that platforms having
> a 48-bit PA can select that option. But having it will create the code something
> like below
>
> #ifndef CONFIG_ARM64_64KB_PAGES
> #ifdef CONFIG_ARCH_SUPPORTS_48BIT_PA
> ...
> ..
> #else
> ..
> ..
> #endif
> #else /* !CONFIG_ARM64_64KB_PAGES */
> #ifdef CONFIG_ARCH_SUPPORTS_48BIT_PA
> ..
> ..
> #else
> ..
> ..
> #endif
> #endif /* CONFIG_ARM64_64KB_PAGES */
>
> And we might need to do this at lot of places. Is this ok?
>

Before going for a next version of patch to fix breaking SMMU and KVM,
I would like to know  about the best possible implementation.
Should I go for a compile time option? I am not in favor of this. What
are options if in future there's 16KB page support in the kernel.

Penalties for platforms that do not have a 48-bit PA are an extra
lookup and extra memory space for another pagetable. We don't have an
actual hardware to get an reliable data.
If someone can try this on a real hardware I would like to know.



More information about the linux-arm-kernel mailing list