aboutsummaryrefslogtreecommitdiff
path: root/hw/arm/boot.c
AgeCommit message (Collapse)Author
2020-12-15vl: make qemu_get_machine_opts staticPaolo Bonzini
Machine options can be retrieved as properties of the machine object. Encourage that by removing the "easy" accessor to machine options. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-12-10vl: extract softmmu/datadir.cPaolo Bonzini
Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-02hw/arm/boot: fix SVE for EL3 direct kernel bootRémi Denis-Courmont
When booting a CPU with EL3 using the -kernel flag, set up CPTR_EL3 so that SVE will not trap to EL3. Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20201030151541.11976-1-remi@remlab.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-27hw/arm/boot: Fix MTE for EL3 direct kernel bootRichard Henderson
When booting an EL3 cpu with -kernel, we set up EL3 and then drop down to EL2. We need to enable access to v8.5-MemTag tag allocation at EL3 before doing so. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200724163853.504655-3-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-27hw/arm/boot: Fix PAUTH for EL3 direct kernel bootRichard Henderson
When booting an EL3 cpu with -kernel, we set up EL3 and then drop down to EL2. We need to enable access to v8.3-PAuth keys and instructions at EL3 before doing so. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200724163853.504655-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-02-20Remove unnecessary cast when using the address_space APIPhilippe Mathieu-Daudé
This commit was produced with the included Coccinelle script scripts/coccinelle/exec_rw_const. Two lines in hw/net/dp8393x.c that Coccinelle produced that were over 80 characters were re-wrapped by hand. Suggested-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-01-29hw/core/loader: Let load_elf() populate a field with CPU-specific flagsAleksandar Markovic
While loading the executable, some platforms (like AVR) need to detect CPU type that executable is built for - and, with this patch, this is enabled by reading the field 'e_flags' of the ELF header of the executable in question. The change expands functionality of the following functions: - load_elf() - load_elf_as() - load_elf_ram() - load_elf_ram_sym() The argument added to these functions is called 'pflags' and is of type 'uint32_t*' (that matches 'pointer to 'elf_word'', 'elf_word' being the type of the field 'e_flags', in both 32-bit and 64-bit variants of ELF header). Callers are allowed to pass NULL as that argument, and in such case no lookup to the field 'e_flags' will happen, and no information will be returned, of course. CC: Richard Henderson <rth@twiddle.net> CC: Peter Maydell <peter.maydell@linaro.org> CC: Edgar E. Iglesias <edgar.iglesias@gmail.com> CC: Michael Walle <michael@walle.cc> CC: Thomas Huth <huth@tuxfamily.org> CC: Laurent Vivier <laurent@vivier.eu> CC: Philippe Mathieu-Daudé <f4bug@amsat.org> CC: Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com> CC: Aurelien Jarno <aurelien@aurel32.net> CC: Jia Liu <proljc@gmail.com> CC: David Gibson <david@gibson.dropbear.id.au> CC: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> CC: BALATON Zoltan <balaton@eik.bme.hu> CC: Christian Borntraeger <borntraeger@de.ibm.com> CC: Thomas Huth <thuth@redhat.com> CC: Artyom Tarasenko <atar4qemu@gmail.com> CC: Fabien Chouteau <chouteau@adacore.com> CC: KONRAD Frederic <frederic.konrad@adacore.com> CC: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Aleksandar Rikalo <aleksandar.rikalo@rt-rk.com> Signed-off-by: Michael Rolnik <mrolnik@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com> Message-Id: <1580079311-20447-24-git-send-email-aleksandar.markovic@rt-rk.com>
2019-11-11hw/arm/boot: Set NSACR.{CP11, CP10} in dummy SMC setup routineClement Deschamps
The boot.c code usually puts the CPU into NS mode directly when it is booting a kernel. Since fc1120a7f5f2d4b6 this has included a requirement to set NSACR to give NS state access to the FPU; we fixed that for the usual code path in ece628fcf6. However, it is also possible for a board model to request an alternative mode of booting, where its 'board_setup' code hook runs in Secure state and is responsible for doing the S->NS transition after it has done whatever work it must do in Secure state. In this situation the board_setup code now also needs to update NSACR. This affects all boards which set info->secure_board_setup, which is currently the 'raspi' and 'highbank' families. They both use the common arm_write_secure_board_setup_dummy_smc(). Set the NSACR CP11 and CP10 bits in the code written by that function, to allow FPU access in Non-Secure state when using dummy SMC setup routine. Otherwise an AArch32 kernel booted on the highbank or raspi boards will UNDEF as soon as it tries to use the FPU. Update the comment describing secure_board_setup to note the new requirements on users of it. This fixes a kernel panic when booting raspbian on raspi2. Successfully tested with: 2017-01-11-raspbian-jessie-lite.img 2018-11-13-raspbian-stretch-lite.img 2019-07-10-raspbian-buster-lite.img Fixes: fc1120a7f5 Signed-off-by: Clement Deschamps <clement.deschamps@greensocs.com> Tested-by: Laurent Bonnans <laurent.bonnans@here.com> Message-id: 20191104151137.81931-1-clement.deschamps@greensocs.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: updated comment to boot.h to note new requirement on users of secure_board_setup; edited/rewrote commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-11-01hw/arm/boot: Rebuild hflags when modifying CPUState at bootEdgar E. Iglesias
Rebuild hflags when modifying CPUState at boot. Fixes: e979972a6a Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-id: 20191031040830.18800-2-edgar.iglesias@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-09-27hw/arm/boot: Use the IEC binary prefix definitionsPhilippe Mathieu-Daudé
IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190923131108.21459-1-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-09-27hw/arm/boot.c: Set NSACR.{CP11,CP10} for NS kernel bootsPeter Maydell
If we're booting a Linux kernel directly into Non-Secure state on a CPU which has Secure state, then make sure we set the NSACR CP11 and CP10 bits, so that Non-Secure is allowed to access the FPU. Otherwise an AArch32 kernel will UNDEF as soon as it tries to use the FPU. It used to not matter that we didn't do this until commit fc1120a7f5f2d4b6, where we implemented actually honouring these NSACR bits. The problem only exists for CPUs where EL3 is AArch32; the equivalent AArch64 trap bits are in CPTR_EL3 and are "0 to not trap, 1 to trap", so the reset value of the register permits NS access, unlike NSACR. Fixes: fc1120a7f5 Fixes: https://bugs.launchpad.net/qemu/+bug/1844597 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190920174039.3916-1-peter.maydell@linaro.org
2019-09-03numa: move numa global variable numa_info into MachineStateTao Xu
Move existing numa global numa_info (renamed as "nodes") into NumaState. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190809065731.9097-5-tao3.xu@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-09-03numa: move numa global variable nb_numa_nodes into MachineStateTao Xu
Add struct NumaState in MachineState and move existing numa global nb_numa_nodes(renamed as "num_nodes") into NumaState. And add variable numa_support into MachineClass to decide which submachines support NUMA. Reviewed-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190809065731.9097-3-tao3.xu@intel.com> [ehabkost: include hw/boards.h again to fix build failures] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-09-03hw/arm: simplify arm_load_dtbTao Xu
In struct arm_boot_info, kernel_filename, initrd_filename and kernel_cmdline are copied from from MachineState. This patch add MachineState as a parameter into arm_load_dtb() and move the copy chunk of kernel_filename, initrd_filename and kernel_cmdline into arm_load_kernel(). Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Liu Jingqi <jingqi.liu@intel.com> Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Tao Xu <tao3.xu@intel.com> Message-Id: <20190809065731.9097-2-tao3.xu@intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Cédric Le Goater <clg@kaod.org> [ehabkost: include hw/boards.h again to fix build failures] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-16Include hw/boards.h a bit lessMarkus Armbruster
hw/boards.h pulls in almost 60 headers. The less we include it into headers, the better. As a first step, drop superfluous inclusions, and downgrade some more to what's actually needed. Gets rid of just one inclusion into a header. Cc: Eduardo Habkost <ehabkost@redhat.com> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-23-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
2019-08-16Include hw/hw.h exactly where neededMarkus Armbruster
In my "build everything" tree, changing hw/hw.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The previous commits have left only the declaration of hw_error() in hw/hw.h. This permits dropping most of its inclusions. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-19-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include sysemu/reset.h a lot lessMarkus Armbruster
In my "build everything" tree, changing sysemu/reset.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The main culprit is hw/hw.h, which supposedly includes it for convenience. Include sysemu/reset.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-9-armbru@redhat.com>
2019-07-26hw/arm/boot: Further improve initrd positioning codePeter Maydell
In commit e6b2b20d9735d4ef we made the boot loader code try to avoid putting the initrd on top of the kernel. However the expression used to calculate the start of the initrd: info->initrd_start = info->loader_start + MAX(MIN(info->ram_size / 2, 128 * 1024 * 1024), kernel_size); incorrectly uses 'kernel_size' as the offset within RAM of the highest address to avoid. This is incorrect because the kernel doesn't start at address 0, but slightly higher than that. This means that we can still incorrectly end up overlaying the initrd on the kernel in some cases, for example: * The kernel's image_size is 0x0a7a8000 * The kernel was loaded at 0x40080000 * The end of the kernel is 0x4A828000 * The DTB was loaded at 0x4a800000 To get this right we need to track the actual highest address used by the kernel and use that rather than kernel_size. We already set image_low_addr and image_high_addr for ELF images; set them also for the various other image types we support, and then use image_high_addr as the lowest allowed address for the initrd. (We don't use image_low_addr, but we set it for consistency with the existing code path for ELF files.) Fixes: e6b2b20d9735d4ef Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190722151804.25467-3-peter.maydell@linaro.org
2019-07-26hw/arm/boot: Rename elf_{low, high}_addr to image_{low, high}_addrPeter Maydell
Rename the elf_low_addr and elf_high_addr variables to image_low_addr and image_high_addr -- in the next commit we will extend them to be set for other kinds of image file and not just ELF files. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190722151804.25467-2-peter.maydell@linaro.org
2019-07-01hw/arm/boot: fix direct kernel boot with initrdAndrew Jones
Fix the condition used to check whether the initrd fits into RAM; in some cases if an initrd was also passed on the command line we would get an error stating that it was too big to fit into RAM after the kernel. Despite the error the loader continued anyway, though, so also add an exit(1) when the initrd is actually too big. Fixes: 852dc64d665f ("hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAM") Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190618125844.4863-1-drjones@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-06-17hw/arm/boot: Honour image size field in AArch64 Image format kernelsPeter Maydell
Since Linux v3.17, the kernel's Image header includes a field image_size, which gives the total size of the kernel including unpopulated data sections such as the BSS). If this is present, then return it from load_aarch64_image() as the true size of the kernel rather than just using the size of the Image file itself. This allows the code which calculates where to put the initrd to avoid putting it in the kernel's BSS area. This means that we should be able to reliably load kernel images which are larger than 128MB without accidentally putting the initrd or dtb in locations that clash with the kernel itself. Fixes: https://bugs.launchpad.net/qemu/+bug/1823998 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-5-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Avoid placing the initrd on top of the kernelPeter Maydell
We currently put the initrd at the smaller of: * 128MB into RAM * halfway into the RAM (with the dtb following it). However for large kernels this might mean that the kernel overlaps the initrd. For some kinds of kernel (self-decompressing 32-bit kernels, and ELF images with a BSS section at the end) we don't know the exact size, but even there we have a minimum size. Put the initrd at least further into RAM than that. For image formats that can give us an exact kernel size, this will mean that we definitely avoid overlaying kernel and initrd. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-4-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAMPeter Maydell
We calculate the locations in memory where we want to put the initrd and the DTB based on the size of the kernel, since they come after it. Add some explicit checks that these aren't off the end of RAM entirely. (At the moment the way we calculate the initrd_start means that it can't ever be off the end of RAM, but that will change with the next commit.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-3-peter.maydell@linaro.org
2019-06-17hw/arm/boot: Don't assume RAM starts at address zeroPeter Maydell
In the Arm kernel/initrd loading code, in some places we make the incorrect assumption that info->ram_size can be treated as the address of the end of RAM, as for instance when we calculate the available space for the initrd using "info->ram_size - info->initrd_start". This is wrong, because many Arm boards (including "virt") specify a non-zero info->loader_start to indicate that their RAM area starts at a non-zero physical address. Correct the places which make this incorrect assumption. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Mark Rutland <mark.rutland@arm.com> Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-05-23arm: Rename hw/arm/arm.h to hw/arm/boot.hPeter Maydell
The header file hw/arm/arm.h now includes only declarations relating to hw/arm/boot.c functionality. Rename it accordingly, and adjust its header comment. The bulk of this commit was created via perl -pi -e 's|hw/arm/arm.h|hw/arm/boot.h|' hw/arm/*.c include/hw/arm/*.h In a few cases we can just delete the #include: hw/arm/msf2-soc.c, include/hw/arm/aspeed_soc.h and include/hw/arm/bcm2836.h did not require it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190516163857.6430-4-peter.maydell@linaro.org
2019-03-05hw/arm/boot: introduce fdt_add_memory_node helperShameer Kolothum
We introduce an helper to create a memory node. Signed-off-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190304101339.25970-2-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-05Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* cpu-exec fixes (Emilio, Laurent) * TCG bugfix in queue.h (Paolo) * high address load for linuxboot (Zhijian) * PVH support (Liam, Stefano) * misc i386 changes (Paolo, Robert, Doug) * configure tweak for openpty (Thomas) * elf2dmp port to Windows (Viktor) * initial improvements to Makefile infrastructure (Yang + GSoC 2013) # gpg: Signature made Tue 05 Feb 2019 17:34:42 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (76 commits) queue: fix QTAILQ_FOREACH_REVERSE_SAFE scsi-generic: Convert from DPRINTF() macro to trace events scsi-disk: Convert from DPRINTF() macro to trace events pc: Use hotplug_handler_(plug|unplug|unplug_request) i386: hvf: Fix smp boot hangs hw/vfio/Makefile.objs: Create new CONFIG_* variables for VFIO core and PCI hw/i2c/Makefile.objs: Create new CONFIG_* variables for EEPROM and ACPI controller hw/tricore/Makefile.objs: Create CONFIG_* for tricore hw/openrisc/Makefile.objs: Create CONFIG_* for openrisc hw/moxie/Makefile.objs: Conditionally build moxie hw/hppa/Makefile.objs: Create CONFIG_* for hppa hw/cris/Makefile.objs: Create CONFIG_* for cris hw/alpha/Makefile.objs: Create CONFIG_* for alpha hw/sparc64/Makefile.objs: Create CONFIG_* for sparc64 hw/riscv/Makefile.objs: Create CONFIG_* for riscv boards hw/nios2/Makefile.objs: Conditionally build nios2 hw/xtensa/Makefile.objs: Build xtensa_sim and xtensa_fpga conditionally hw/lm32/Makefile.objs: Conditionally build lm32 and milkmyst hw/sparc/Makefile.objs: CONFIG_* for sun4m and leon3 created hw/s390/Makefile.objs: Create new CONFIG_* variables for s390x boards and devices ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # qemu-deprecated.texi
2019-02-05hw/arm/boot: Support DTB autoload for firmware-only bootsPeter Maydell
The arm_boot_info struct has a skip_dtb_autoload flag: if this is set to true by the board code then arm_load_kernel() will not load the DTB itself, but will leave this for the board code to do itself later. However, the check for this is done in a code path which is only executed for the case where we load a kernel image file. If we're taking the "boot via firmware" code path then the flag isn't honoured and the DTB is never loaded. We didn't notice this because the only real user of "boot via firmware" that cares about the DTB is the virt board (for UEFI boot), and that always wants skip_dtb_autoload anyway. But the SBSA reference board model we're planning to add will want the flag to behave correctly. Now we've refactored the arm_load_kernel() function, the fix is simple: drop the early 'return' so we fall into the same "load the DTB" code the boot-direct-kernel path uses. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-6-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Clarify why arm_setup_firmware_boot() doesn't set env->boot_infoPeter Maydell
The code path for booting firmware doesn't set env->boot_info. At first sight this looks odd, so add a comment saying why we don't. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-5-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Factor out "set up firmware boot" codePeter Maydell
Factor out the "boot via firmware" code path from arm_load_kernel() into its own function. This commit only moves code around; no semantic changes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-4-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Factor out "direct kernel boot" code into its own functionPeter Maydell
Factor out the "direct kernel boot" code path from arm_load_kernel() into its own function; this function is getting long enough that the code flow is a bit confusing. This commit only moves code around; no semantic changes. We leave the "load the dtb" code in arm_load_kernel() -- this is currently only used by the "direct kernel boot" path, but this is a bug which we will fix shortly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-3-peter.maydell@linaro.org
2019-02-05hw/arm/boot: Fix block comment style in arm_load_kernel()Peter Maydell
Fix the block comment style in arm_load_kernel() to QEMU's current style preferences. This will allow us to do some refactoring of this function without checkpatch complaining about the code-motion patches. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190131112240.8395-2-peter.maydell@linaro.org
2019-02-05elf: Add optional function ptr to load_elf() to parse ELF notesLiam Merwick
This patch adds an optional function pointer, 'elf_note_fn', to load_elf() which causes load_elf() to additionally parse any ELF program headers of type PT_NOTE and check to see if the ELF Note is of the type specified by the 'translate_opaque' arg. If a matching ELF Note is found then the specfied function pointer is called to process the ELF note. Passing a NULL function pointer results in ELF Notes being skipped. The first consumer of this functionality is the PVHboot support which needs to read the XEN_ELFNOTE_PHYS32_ENTRY ELF Note while loading the uncompressed kernel binary in order to discover the boot entry address for the x86/HVM direct boot ABI. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-01arm: Clarify the logic of set_pc()Julia Suvorova
Until now, the set_pc logic was unclear, which raised questions about whether it should be used directly, applying a value to PC or adding additional checks, for example, set the Thumb bit in Arm cpu. Let's set the set_pc logic for “Configure the PC, as was done in the ELF file” and implement synchronize_with_tb hook for preserving PC to cpu_tb_exec. Signed-off-by: Julia Suvorova <jusual@mail.ru> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20190129121817.7109-1-jusual@mail.ru Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-01-07Support u-boot noload images for arm as used by, NetBSD/evbarm GENERIC kernel.Nick Hudson
noload kernels are loaded with the u-boot image header and as a result the header size needs adding to the entry point. Fake up a hdr so the kernel image is loaded at the right address and the entry point is adjusted appropriately. The default location for the uboot file is 32MiB above bottom of DRAM. This matches the recommendation in Documentation/arm/Booting. Clarify the load_uimage API to state the passing of a load address when an image doesn't specify one, or when loading a ramdisk is expected. Adjust callers of load_uimage, etc. Signed-off-by: Nick Hudson <skrll@netbsd.org> Message-id: 11488a08-1fe0-a278-2210-deb64731107f@gmx.co.uk Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-12-13Allow AArch64 processors to boot from a kernel placed over 4GBRicardo Perez Blanco
Architecturally, it's possible for an AArch64 machine to have all of its RAM over the 4GB mark, but our kernel/initrd loading code in boot.c assumes that the upper half of the addresses to load these images to is always zero. Write the whole 64 bit address into the bootloader code fragment, not just the low half. Note that, currently, none of the existing QEMU machines have their main memory over 4GBs, so this was not a user-visible bug. Signed-off-by: Ricardo Perez Blanco <ricardo.perez_blanco@nokia.com> [PMM: revised commit message and tweaked some long lines] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-10-24hw/arm/boot: Increase compliance with kernel arm64 boot protocolStewart Hildebrand
"The Image must be placed text_offset bytes from a 2MB aligned base address anywhere in usable system RAM and called there." For the virt board, we write our startup bootloader at the very bottom of RAM, so that bit can't be used for the image. To avoid overlap in case the image requests to be loaded at an offset smaller than our bootloader, we increment the load offset to the next 2MB. This fixes a boot failure for Xen AArch64. Signed-off-by: Stewart Hildebrand <stewart.hildebrand@dornerworks.com> Tested-by: Andre Przywara <andre.przywara@arm.com> Message-id: b8a89518794b4436af0c151ed10de4fa@dornerworks.com [PMM: Rephrased a comment a bit] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-08-24hw/arm/boot: AArch32 kernels should be started in Hyp mode if availablePeter Maydell
The kernel booting specification for an AArch32 kernel requires that it is booted in Hyp mode if available; otherwise the kernel can't enable KVM. We were incorrectly leaving the kernel in SVC mode. If we're booting an AArch32 kernel in the Nonsecure state and Hyp mode is available, start in it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-id: 20180820153020.21478-7-peter.maydell@linaro.org
2018-08-14arm: Fix return code of arm_load_elfAdam Lackorzynski
Use an int64_t as a return type to restore the negative check for arm_load_as. Signed-off-by: Adam Lackorzynski <adam@l4re.org> Message-id: 20180730173712.GG4987@os.inf.tu-dresden.de Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-06-29hw/arm/virt: Silence dtc /memory warningEric Auger
When running dtc on the guest /proc/device-tree we get the following warning: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name". Let's fix that by adding the unit address to the node name. We also don't create the /memory node anymore in create_fdt(). We directly create it in load_dtb. /chosen still needs to be created in create_fdt as the uart needs it. In case the user provided his own dtb, we nop all memory nodes found in root and create new one(s). Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-id: 1530044492-24921-4-git-send-email-eric.auger@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-31arm: fix qemu crash on startup with -bios optionIgor Mammedov
When QEMU is started with following CLI -machine virt,gic-version=3,accel=kvm -cpu host -bios AAVMF_CODE.fd it crashes with abort at accel/kvm/kvm-all.c:2164: KVM_SET_DEVICE_ATTR failed: Group 6 attr 0x000000000000c665: Invalid argument Which is caused by implicit dependency of kvm_arm_gicv3_reset() on arm_gicv3_icc_reset() where the later is called by CPU reset reset callback. However commit: 3b77f6c arm/boot: split load_dtb() from arm_load_kernel() broke CPU reset callback registration in case arm_load_kernel() ... if (!info->kernel_filename || info->firmware_loaded) branch is taken, i.e. it's sufficient to provide a firmware or do not provide kernel on CLI to skip cpu reset callback registration, where before offending commit the callback has been registered unconditionally. Fix it by registering the callback right at the beginning of arm_load_kernel() unconditionally instead of doing it at the end. NOTE: we probably should eliminate that dependency anyways as well as separate arch CPU reset parts from arm_load_kernel() into CPU itself, but that refactoring that I probably would have to do anyways later for CPU hotplug to work. Reported-by: Auger Eric <eric.auger@redhat.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-id: 1527070950-208350-1-git-send-email-imammedo@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-10arm/boot: split load_dtb() from arm_load_kernel()Igor Mammedov
load_dtb() depends on arm_load_kernel() to figure out place in RAM where it should be loaded, but it's not required for arm_load_kernel() to work. Sometimes it's neccesary for devices added with -device/device_add to be enumerated in DTB as well, which's lead to [1] and surrounding commits to add 2 more machine_done notifiers with non obvious ordering to make dynamic sysbus devices initialization happen in the right order. However instead of moving whole arm_load_kernel() in to machine_done, it's sufficient to move only load_dtb() into virt_machine_done() notifier and remove ArmLoadKernelNotifier/ /PlatformBusFDTNotifierParams notifiers, which saves us ~90LOC and simplifies code flow quite a bit. Later would allow to consolidate DTB generation within one function for 'mach-virt' board and make it reentrant so it could generate updated DTB in device hotplug secenarios. While at it rename load_dtb() to arm_load_dtb() since it's public now. Add additional field skip_dtb_autoload to struct arm_boot_info to allow manual DTB load later in mach-virt and to avoid touching all other boards to explicitly call arm_load_dtb(). 1) (ac9d32e hw/arm/boot: arm_load_kernel implemented as a machine init done notifier) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 1525691524-32265-4-git-send-email-imammedo@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-05-04arm: boot: set boot_info starting from first_cpuIgor Mammedov
Even though nothing is currently broken (since all boards use first_cpu as boot cpu), make sure that boot_info is set on all CPUs. If some board would like support heterogenuos setup (i.e. init boot_info on subset of CPUs) in future, it should add a reasonable API to do it, instead of starting assigning boot_info from some CPU and till the end of present CPUs list. Ref: "Message-ID: <CAFEAcA_NMWuA8WSs3cNeY6xX1kerO_uAcN_3=fK02BEhHJW86g@mail.gmail.com>" Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1525176522-200354-5-git-send-email-imammedo@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-26arm: always start from first_cpu when registering loader cpu reset callbackIgor Mammedov
if arm_load_kernel() were passed non first_cpu, QEMU would end up with partially set do_cpu_reset() callback leaving some CPUs without it. Make sure that do_cpu_reset() is registered for all CPUs by enumerating CPUs from first_cpu. (In practice every board that we have was passing us the first CPU as the boot CPU, either directly or indirectly, so this wasn't causing incorrect behaviour.) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added a note that this isn't a behaviour change] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-10hw/arm: Allow manually specified /psci nodeAndrey Smirnov
Change the code to avoid exiting QEMU if user provided DTB contains manually specified /psci node and skip any /psci related fixups instead. Fixes: 4cbca7d9b4 ("hw/arm: Move virt's PSCI DT fixup code to arm/boot.c") Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reported-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Message-id: 20180402205654.14572-1-andrew.smirnov@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-19hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCEPeter Maydell
If we're directly booting a Linux kernel and the CPU supports both EL3 and EL2, we start the kernel in EL2, as it expects. We must also set the SCR_EL3.HCE bit in this situation, so that the HVC instruction is enabled rather than UNDEFing. Otherwise at least some kernels will panic when trying to initialize KVM in the guest. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20180313153458.26822-4-peter.maydell@linaro.org
2018-03-19hw/arm/boot: assert that secure_boot and secure_board_setup are false for ↵Peter Maydell
AArch64 Add some assertions that if we're about to boot an AArch64 kernel, the board code has not mistakenly set either secure_boot or secure_board_setup. It doesn't make sense to set secure_boot, because all AArch64 kernels must be booted in non-secure mode. It might in theory make sense to set secure_board_setup, but we don't currently support that, because only the AArch32 bootloader[] code calls this hook; bootloader_aarch64[] does not. Since we don't have a current need for this functionality, just assert that we don't try to use it. If it's needed we'll add it later. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-3-peter.maydell@linaro.org
2018-03-09arm: avoid heap-buffer-overflow in load_aarch64_imageMarc-André Lureau
Spotted by ASAN: elmarco@boraha:~/src/qemu/build (master *%)$ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 tests/boot-serial-test /aarch64/boot-serial/virt: ** (process:19740): DEBUG: 18:39:30.275: foo /tmp/qtest-boot-serial-cXaS94D ================================================================= ==19740==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000069648 at pc 0x7f1d2201cc54 bp 0x7fff331f6a40 sp 0x7fff331f61e8 READ of size 4 at 0x603000069648 thread T0 #0 0x7f1d2201cc53 (/lib64/libasan.so.4+0xafc53) #1 0x55bc86685ee3 in load_aarch64_image /home/elmarco/src/qemu/hw/arm/boot.c:894 #2 0x55bc86687217 in arm_load_kernel_notify /home/elmarco/src/qemu/hw/arm/boot.c:1047 #3 0x55bc877363b5 in notifier_list_notify /home/elmarco/src/qemu/util/notify.c:40 #4 0x55bc869331ea in qemu_run_machine_init_done_notifiers /home/elmarco/src/qemu/vl.c:2716 #5 0x55bc8693bc39 in main /home/elmarco/src/qemu/vl.c:4679 #6 0x7f1d1652c009 in __libc_start_main (/lib64/libc.so.6+0x21009) #7 0x55bc86255cc9 in _start (/home/elmarco/src/qemu/build/aarch64-softmmu/qemu-system-aarch64+0x1ae5cc9) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09arm: fix load ELF error leakMarc-André Lureau
Spotted by ASAN: QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 tests/boot-serial-test Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7ff8a9b0ca38 in __interceptor_calloc (/lib64/libasan.so.4+0xdea38) #1 0x7ff8a8ea7f75 in g_malloc0 ../glib/gmem.c:124 #2 0x55fef3d99129 in error_setv /home/elmarco/src/qemu/util/error.c:59 #3 0x55fef3d99738 in error_setg_internal /home/elmarco/src/qemu/util/error.c:95 #4 0x55fef323acb2 in load_elf_hdr /home/elmarco/src/qemu/hw/core/loader.c:393 #5 0x55fef2d15776 in arm_load_elf /home/elmarco/src/qemu/hw/arm/boot.c:830 #6 0x55fef2d16d39 in arm_load_kernel_notify /home/elmarco/src/qemu/hw/arm/boot.c:1022 #7 0x55fef3dc634d in notifier_list_notify /home/elmarco/src/qemu/util/notify.c:40 #8 0x55fef2fc3182 in qemu_run_machine_init_done_notifiers /home/elmarco/src/qemu/vl.c:2716 #9 0x55fef2fcbbd1 in main /home/elmarco/src/qemu/vl.c:4679 #10 0x7ff89dfed009 in __libc_start_main (/lib64/libc.so.6+0x21009) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-27 05:07:45 +0000