Re: [PATCH v2 00/12] 52-bit kernel + user VAs

On Fri, Jun 07, 2019 at 07:23:59PM +0530, Anshuman Khandual wrote:

Hello Steve,

Hi Anshuman,

On 05/28/2019 09:40 PM, Steve Capper wrote:

quoted

This patch series adds support for 52-bit kernel VAs using some of the
machinery already introduced by the 52-bit userspace VA code in 5.0.

As 52-bit virtual address support is an optional hardware feature,
software support for 52-bit kernel VAs needs to be deduced at early boot
time. If HW support is not available, the kernel falls back to 48-bit.

Just to summarize.

If kernel is configured for 52 bits then it just setups up infrastructure
for 52 bits kernel VA space.

When at the boot

a. Detects HW feature	   -> Use 52 bits VA on 52 bits infra
b. Does not detect feature -> Use 48 bits VA on 52 bits infra (adjusted)

quoted

A significant proportion of this series focuses on "de-constifying"
VA_BITS related constants.

I assume this is required for the situation (b) because of adjustments
at boot time which will be required after detecting that 52 bit is not
supported in the HW.
  

quoted

In order to allow for a KASAN shadow that changes size at boot time, one

Ditto as above ?

quoted

must fix the KASAN_SHADOW_END for both 48 & 52-bit VAs and "grow" the
start address. Also, it is highly desirable to maintain the same

Is there any particular reason why KASAN_SHADOW_START cannot be fixed and
KASAN_SHADOW_END "grow" instead ? Is it because we are trying to make start
address (which will be closer to VA_START) for all required sections variable ?

KASAN has a mode of operation whereby the shadow offset computation:
shadowPtr = (ptr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET 

is inlined into the executable with a constant scale and offset. As we
are dealing with TTBR1 style addresses (i.e. prefixed by 0xfff...) this
effectively means that the KASAN shadow end address becomes fixed (the
highest ptr is always ~0UL which is invariant to VA space size
changes).

The only way that I am aware of fixing the start address is to somehow
patch the KASAN_SHADOW_OFFSET, or prohibit the KASAN inline mode (which
would then hurt performance).

quoted

function addresses in the kernel .text between VA sizes. Both of these

Kernel .text range should remain same as the kernel is already loaded in
memory at boot and executing while also trying to fix the effective VA_BITS
after detecting (or not) the 52 bits HW feature.

quoted

requirements necessitate us to flip the kernel address space halves s.t.
the direct linear map occupies the lower addresses.

Still trying to understand all the reasons for this VA space flip here.

The current kernel 48 bit VA range is split into two halves

1. Higher half	- [UL(~0) ...... PAGE_OFFSET] for linear mapping
2. Lower half	- [PAGE_OFFSET ... VA_START]  for everything else

The split in the middle is based on VA_BITS. When that becomes variable then
boot time computed lower half sections like kernel text, fixed mapping etc
become problematic as they are already running or being used and cannot be
relocated. This is caused by the fact the 48 bits to 52 bits adjustment can
only happen on the VA_START end as the other end UL(~0) is fixed. Hence move
those non-relocatable/fixed sections to  higher half so they dont get impacted
from the 48-52 bits adjustments. Linear mapping (so would PAGE_OFFSET) on the
other hand will have to grow/shrink (or not) during 48-52 bits adjustment.
Hence it can be aligned with the VA_START end instead. Is that correct or I
am missing something.

Agreed with the .text addresses. For PAGE_OFFSET we don't strictly need
it to point to the start of the linear map if we grow the vmemmap and
adjust the (already variable) vmemmap offset (along with physvirt_offset).

Also we need to flip the VA space to fit KASAN in as it will grow from
the start.

quoted

In V2 of this series (apologies for the long delay from V1), the major
change is that PAGE_OFFSET is retained as a constant. This allows for
much faster virt_to_page computations. This is achieved by expanding the

virt_to_page(), __va(), __pa() needs to be based on just linear offset
calculations else there will be performance impact. 

IIUC I've maintained equal perf for these, but if I've missed something
please shout :-).

quoted

size of the VMEMMAP region to accommodate a disjoint 52-bit/48-bit
direct linear map. This has been found to work well in my testing, but I

I assume it means that we create linear mapping for the entire 52 bit VA
space but back it up with vmmmap struct page mapping only for the actual
bits (48 or 52) in use.

That is my understanding too.

A big thank you for looking at this!

Cheers,
-- 
Steve

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