Skip to content

Conversation

@slp
Copy link
Collaborator

@slp slp commented Nov 28, 2025

EDK2 expects RAM to start at 0x4000_0000, and a while ago we decided to
make this default for both the EFI and non-EFI flavors. The problem with
this approach is that, on aarch64, the Linux kernel expects to be loaded
at 0x8000_0000, meaning that region needs to be covered by RAM.

For large VMs this isn't a problem but for VMs smaller than 1GB, that
region gets uncovered. In theory, we could add another region dedicated
to the kernel at 0x8000_0000 and let the rest of RAM start at
0x4000_0000, but this has two problems:

- We would be using more RAM than what we were configured to.
- It's very hard to find out exactly the size of the kernel region.

So, instead, let's go back to use two different start addresses,
depending on wether we're booting a firmware or a kernel, but let's do
it in a cleaner way, so we don't depend on having an independent flavor.

Fixes: #460

For the KernelCopy payload, check that the kernel really fits in memory
before copying it. We were counting on guest_mem.write() to fail if the
addresses are outside the covered regions, but this may not happen if
we've added shared memory regions to the guest memory. Checking against
arch_mem_info.ram_last_addr is more reliable.

Signed-off-by: Sergio Lopez <[email protected]>
@slp slp force-pushed the aarch64-small-vms branch from 59792b6 to 214e62a Compare November 28, 2025 12:29
slp added 4 commits November 28, 2025 15:45
Remove deprecated get_kernel_start and initrd_load_addr methods.

Signed-off-by: Sergio Lopez <[email protected]>
Calculate the right place to put the fdt in arch_memory_regions, save
the value in ArchMemoryInfo, and deprecate get_fdt_addr().

Signed-off-by: Sergio Lopez <[email protected]>
EDK2 expects RAM to start at 0x4000_0000, and a while ago we decided to
make this default for both the EFI and non-EFI flavors. The problem with
this approach is that, on aarch64, the Linux kernel expects to be loaded
at 0x8000_0000, meaning that region needs to be covered by RAM.

For large VMs this isn't a problem but for VMs smaller than 1GB, that
region gets uncovered. In theory, we could add another region dedicated
to the kernel at 0x8000_0000 and let the rest of RAM start at
0x4000_0000, but this has two problems:

- We would be using more RAM than what we were configured to.
- It's very hard to find out exactly the size of the kernel region.

So, instead, let's go back to use two different start addresses,
depending on wether we're booting a firmware or a kernel, but let's do
it in a cleaner way, so we don't depend on having an independent flavor.

Fixes: containers#460

Signed-off-by: Sergio Lopez <[email protected]>
When booting a firmware, RAM starts at 0x4000_0000, while when doing a
direct kernel boot RAM starts at 0x8000_0000. Only write SMBIOS in the
former case.

Signed-off-by: Sergio Lopez <[email protected]>
@slp slp force-pushed the aarch64-small-vms branch from 214e62a to 13f11da Compare November 28, 2025 14:45
@slp slp marked this pull request as ready for review November 28, 2025 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant