blob: 268c3dc0c60e0cc49bcff0764e2a3940136ad48e (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
debug: 0.959
architecture: 0.942
arm: 0.831
kernel: 0.821
performance: 0.803
boot: 0.796
device: 0.775
files: 0.685
network: 0.616
ppc: 0.596
socket: 0.582
register: 0.560
permissions: 0.546
mistranslation: 0.530
PID: 0.520
peripherals: 0.510
x86: 0.509
semantic: 0.506
user-level: 0.501
graphic: 0.451
i386: 0.435
VMM: 0.430
vnc: 0.429
hypervisor: 0.418
TCG: 0.409
risc-v: 0.399
virtual: 0.392
KVM: 0.379
assembly: 0.265
qemu-system-aarch64: support kernels bigger than 128MiB
Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd.
This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure.
Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68
It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel.
I've submitted a patchset which I think should fix this, but if you could test that it actually does handle large images correctly that would be great.
https://<email address hidden>/
Changes now in master, will be in 4.1.
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5e6dbe1e8cbbe4b6f74
|