On Mon, 10 Jul 2023 at 20:33, Glenn Washburn <developm...@efficientek.com> wrote: > > Non-x86 EFI architectures were using a INITRD_MAX_ADDRESS_OFFSET defined > by the aarch64 architecture. This seems to generally work, as in no one > has complained about this. However, the code is misleading. Architectures > should explicitly set INITRD_MAX_ADDRESS_OFFSET. To avoid breaking current > EFI architectures, set to GRUB_EFI_MAX_USABLE_ADDRESS, effectively allowing > the entire address range. New architectures will fail to build until this > macro is set. > > Signed-off-by: Glenn Washburn <developm...@efficientek.com> > --- > My reading of a reply on the list[1] is that RISCV has no limit for the > initrd. But I think it would be good to point to documentation describing > limitations as in the ARM comments. >
AIUI, RISC-V may support 3, 4 or 5 levels of paging, and it may depend on the kernel configuration which of those are actually supported. This may affect the addressability of the linear region, and given EDK2's tendency to allocate from the top of memory downwards, imposing no limit at all may result allocations that the kernel cannot access. That said, is this even an issue for RISC-V? As far as I remember, the LoadFile2 based initrd loading method was supported from the beginning, and so this is mostly dead code anyway on RISC-V, and perhaps it would be better to simply disable it. > > [1] https://lists.gnu.org/archive/html/grub-devel/2021-07/msg00001.html > --- > grub-core/loader/efi/linux.c | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/grub-core/loader/efi/linux.c b/grub-core/loader/efi/linux.c > index ab8fb35adb05..8f5460ba11e0 100644 > --- a/grub-core/loader/efi/linux.c > +++ b/grub-core/loader/efi/linux.c > @@ -28,6 +28,7 @@ > #include <grub/efi/efi.h> > #include <grub/efi/fdtload.h> > #include <grub/efi/memory.h> > +#include <grub/cpu/efi/memory.h> > #include <grub/efi/pe32.h> > #include <grub/efi/sb.h> > #include <grub/i18n.h> > @@ -290,21 +291,30 @@ grub_linux_unload (void) > } > > #if !defined(__i386__) && !defined(__x86_64__) > +#if defined (__arm__) > /* > * As per linux/Documentation/arm/Booting > * ARM initrd needs to be covered by kernel linear mapping, > * so place it in the first 512MB of DRAM. > - * > + */ > +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > +#elif defined (__aarch64__) > +/* > * As per linux/Documentation/arm64/booting.txt > * ARM64 initrd needs to be contained entirely within a 1GB aligned window > * of up to 32GB of size that covers the kernel image as well. > * Since the EFI stub loader will attempt to load the kernel near start of > * RAM, place the buffer in the first 32GB of RAM. > */ > -#ifdef __arm__ > -#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024) > -#else /* __aarch64__ */ > #define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024) > +#elif defined (__ia64__) || defined (__riscv) || defined (__loongarch_lp64) > +/* > + * There has been no investigation into constraints on the initrd address > + * for these platforms. Allow all the available address space for now. > + */ > +#define INITRD_MAX_ADDRESS_OFFSET GRUB_EFI_MAX_USABLE_ADDRESS > +#else > +#error "Unknown INITRD_MAX_ADDRESS_OFFSET for architecture" > #endif > > /* > -- > 2.34.1 > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
