Page MenuHomeFreeBSD

stand/efi: Limit where we load the arm64 kernel
AcceptedPublic

Authored by andrew on Sep 10 2024, 2:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 21, 12:34 AM
Unknown Object (File)
Nov 25 2024, 7:51 AM
Unknown Object (File)
Nov 7 2024, 3:31 AM
Unknown Object (File)
Nov 7 2024, 1:36 AM
Unknown Object (File)
Oct 30 2024, 12:47 PM
Unknown Object (File)
Oct 8 2024, 7:50 PM
Unknown Object (File)
Sep 21 2024, 11:33 AM
Unknown Object (File)
Sep 21 2024, 9:49 AM
Subscribers

Details

Reviewers
alc
kib
markj
manu
Group Reviewers
arm64
Summary

When FEAT_LPA2 is implemented the hardware supports increasing the
physical address space from 48-bit to 52-bit.

As older kernels only support a 48-bit physical address space limit
where the kernel is loaded to this.

Sponsored by: Arm Ltd

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 61086
Build 57970: arc lint + arc unit

Event Timeline

stand/efi/loader/copy.c
311

The - 1 seems inconsistent with the amd64 case above. Which one is right?

stand/efi/loader/copy.c
311

BS->AllocatePages with AllocateMaxAddress can allocate pages where the uppermost address is less than or equal to this value.

It probably doesn't matter to not have the - 1 as no pages above the 1G or 4G mark should be allocated in the amd64 case as they would have to be zero length.

markj added inline comments.
stand/efi/loader/copy.c
311

Then perhaps let's just use (1ul << 48) for consistency's sake?

This revision is now accepted and ready to land.Sep 11 2024, 1:32 PM
stand/efi/loader/copy.c
330

Does this work? I thought that cpp #if only takes arithmetic expressions + defined().

Adjust the AllocateMaxAddress check

This revision now requires review to proceed.Wed, Dec 11, 3:14 PM

Is there any way that we can know if the kernel supports higher loading? Otherwise we'll have this weird quirk forever...

We need to start tagging arm64 kernels that can run about 48 bits so we don't have this workaround around forever

stand/efi/loader/copy.c
440

I'd suggest we do this for all architectures. There's no reason to ifdef this. Otherwise new_base is uninitialized.

Not currently as no kernels support it. We could add an elf note when we support LPA2 in locore.S to tell loader the kernel supports executing from a higher address.

stand/efi/loader/copy.c
440

For an allocation type of AllocateAnyPages this value is ignored in AllocatePages

stand/efi/loader/copy.c
440

The file has way too many ifdefs. This is an easy way to limit that. The arch code will do the right thing..

Not currently as no kernels support it. We could add an elf note when we support LPA2 in locore.S to tell loader the kernel supports executing from a higher address.

That would be great.

In D46625#1094801, @imp wrote:

Not currently as no kernels support it. We could add an elf note when we support LPA2 in locore.S to tell loader the kernel supports executing from a higher address.

That would be great.

For amd64, when I needed to mark kernel as supporting load at arbitrary address below 4G (as opposed of 2M), I check for presence of the magic symbol 'kernphys'.

This revision is now accepted and ready to land.Wed, Dec 11, 5:21 PM