mirror of
https://github.com/izzy2lost/xemu.git
synced 2026-07-06 00:20:22 -07:00
Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-docs-xen-updates-100321-2' into staging
Testing, guest-loader and other misc tweaks - add warning text to quickstart example - add CFI tests to CI - use --arch-only for docker pre-requisites - fix .editorconfig for emacs - add guest-loader for Xen-like hypervisor testing - move generic-loader docs into manual proper - move semihosting out of hw/ # gpg: Signature made Wed 10 Mar 2021 15:35:31 GMT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-testing-docs-xen-updates-100321-2: semihosting: Move hw/semihosting/ -> semihosting/ semihosting: Move include/hw/semihosting/ -> include/semihosting/ tests/avocado: add boot_xen tests docs: add some documentation for the guest-loader docs: move generic-loader documentation into the main manual hw/core: implement a guest-loader to support static hypervisor guests device_tree: add qemu_fdt_setprop_string_array helper hw/riscv: migrate fdt field to generic MachineState hw/board: promote fdt from ARM VirtMachineState to MachineState .editorconfig: update the automatic mode setting for Emacs tests/docker: Use --arch-only when building Debian cross image gitlab-ci.yml: Add jobs to test CFI flags gitlab-ci.yml: Allow custom # of parallel linkers tests/docker: add a test-tcg for building then running check-tcg docs/system: add a gentle prompt for the complexity to come Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell
@@ -0,0 +1,117 @@
|
||||
..
|
||||
Copyright (c) 2016, Xilinx Inc.
|
||||
|
||||
This work is licensed under the terms of the GNU GPL, version 2 or later. See
|
||||
the COPYING file in the top-level directory.
|
||||
|
||||
Generic Loader
|
||||
--------------
|
||||
|
||||
The 'loader' device allows the user to load multiple images or values into
|
||||
QEMU at startup.
|
||||
|
||||
Loading Data into Memory Values
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
The loader device allows memory values to be set from the command line. This
|
||||
can be done by following the syntax below::
|
||||
|
||||
-device loader,addr=<addr>,data=<data>,data-len=<data-len> \
|
||||
[,data-be=<data-be>][,cpu-num=<cpu-num>]
|
||||
|
||||
``<addr>``
|
||||
The address to store the data in.
|
||||
|
||||
``<data>``
|
||||
The value to be written to the address. The maximum size of the data
|
||||
is 8 bytes.
|
||||
|
||||
``<data-len>``
|
||||
The length of the data in bytes. This argument must be included if
|
||||
the data argument is.
|
||||
|
||||
``<data-be>``
|
||||
Set to true if the data to be stored on the guest should be written
|
||||
as big endian data. The default is to write little endian data.
|
||||
|
||||
``<cpu-num>``
|
||||
The number of the CPU's address space where the data should be
|
||||
loaded. If not specified the address space of the first CPU is used.
|
||||
|
||||
All values are parsed using the standard QemuOps parsing. This allows the user
|
||||
to specify any values in any format supported. By default the values
|
||||
will be parsed as decimal. To use hex values the user should prefix the number
|
||||
with a '0x'.
|
||||
|
||||
An example of loading value 0x8000000e to address 0xfd1a0104 is::
|
||||
|
||||
-device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4
|
||||
|
||||
Setting a CPU's Program Counter
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The loader device allows the CPU's PC to be set from the command line. This
|
||||
can be done by following the syntax below::
|
||||
|
||||
-device loader,addr=<addr>,cpu-num=<cpu-num>
|
||||
|
||||
``<addr>``
|
||||
The value to use as the CPU's PC.
|
||||
|
||||
``<cpu-num>``
|
||||
The number of the CPU whose PC should be set to the specified value.
|
||||
|
||||
All values are parsed using the standard QemuOpts parsing. This allows the user
|
||||
to specify any values in any format supported. By default the values
|
||||
will be parsed as decimal. To use hex values the user should prefix the number
|
||||
with a '0x'.
|
||||
|
||||
An example of setting CPU 0's PC to 0x8000 is::
|
||||
|
||||
-device loader,addr=0x8000,cpu-num=0
|
||||
|
||||
Loading Files
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
The loader device also allows files to be loaded into memory. It can load ELF,
|
||||
U-Boot, and Intel HEX executable formats as well as raw images. The syntax is
|
||||
shown below:
|
||||
|
||||
-device loader,file=<file>[,addr=<addr>][,cpu-num=<cpu-num>][,force-raw=<raw>]
|
||||
|
||||
``<file>``
|
||||
A file to be loaded into memory
|
||||
|
||||
``<addr>``
|
||||
The memory address where the file should be loaded. This is required
|
||||
for raw images and ignored for non-raw files.
|
||||
|
||||
``<cpu-num>``
|
||||
This specifies the CPU that should be used. This is an
|
||||
optional argument and will cause the CPU's PC to be set to the
|
||||
memory address where the raw file is loaded or the entry point
|
||||
specified in the executable format header. This option should only
|
||||
be used for the boot image. This will also cause the image to be
|
||||
written to the specified CPU's address space. If not specified, the
|
||||
default is CPU 0. <force-raw> - Setting force-raw=on forces the file
|
||||
to be treated as a raw image. This can be used to load supported
|
||||
executable formats as if they were raw.
|
||||
|
||||
All values are parsed using the standard QemuOpts parsing. This allows the user
|
||||
to specify any values in any format supported. By default the values
|
||||
will be parsed as decimal. To use hex values the user should prefix the number
|
||||
with a '0x'.
|
||||
|
||||
An example of loading an ELF file which CPU0 will boot is shown below::
|
||||
|
||||
-device loader,file=./images/boot.elf,cpu-num=0
|
||||
|
||||
Restrictions and ToDos
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
At the moment it is just assumed that if you specify a cpu-num then
|
||||
you want to set the PC as well. This might not always be the case. In
|
||||
future the internal state 'set_pc' (which exists in the generic loader
|
||||
now) should be exposed to the user so that they can choose if the PC
|
||||
is set or not.
|
||||
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
..
|
||||
Copyright (c) 2020, Linaro
|
||||
|
||||
Guest Loader
|
||||
------------
|
||||
|
||||
The guest loader is similar to the `generic-loader` although it is
|
||||
aimed at a particular use case of loading hypervisor guests. This is
|
||||
useful for debugging hypervisors without having to jump through the
|
||||
hoops of firmware and boot-loaders.
|
||||
|
||||
The guest loader does two things:
|
||||
|
||||
- load blobs (kernels and initial ram disks) into memory
|
||||
- sets platform FDT data so hypervisors can find and boot them
|
||||
|
||||
This is what is typically done by a boot-loader like grub using it's
|
||||
multi-boot capability. A typical example would look like:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|qemu_system| -kernel ~/xen.git/xen/xen \
|
||||
-append "dom0_mem=1G,max:1G loglvl=all guest_loglvl=all" \
|
||||
-device guest-loader,addr=0x42000000,kernel=Image,bootargs="root=/dev/sda2 ro console=hvc0 earlyprintk=xen" \
|
||||
-device guest-loader,addr=0x47000000,initrd=rootfs.cpio
|
||||
|
||||
In the above example the Xen hypervisor is loaded by the -kernel
|
||||
parameter and passed it's boot arguments via -append. The Dom0 guest
|
||||
is loaded into the areas of memory. Each blob will get
|
||||
`/chosen/module@<addr>` entry in the FDT to indicate it's location and
|
||||
size. Additional information can be passed with by using additional
|
||||
arguments.
|
||||
|
||||
Currently the only supported machines which use FDT data to boot are
|
||||
the ARM and RiscV `virt` machines.
|
||||
|
||||
Arguments
|
||||
^^^^^^^^^
|
||||
|
||||
The full syntax of the guest-loader is::
|
||||
|
||||
-device guest-loader,addr=<addr>[,kernel=<file>,[bootargs=<args>]][,initrd=<file>]
|
||||
|
||||
``addr=<addr>``
|
||||
This is mandatory and indicates the start address of the blob.
|
||||
|
||||
``kernel|initrd=<file>``
|
||||
Indicates the filename of the kernel or initrd blob. Both blobs will
|
||||
have the "multiboot,module" compatibility string as well as
|
||||
"multiboot,kernel" or "multiboot,ramdisk" as appropriate.
|
||||
|
||||
``bootargs=<args>``
|
||||
This is an optional field for kernel blobs which will pass command
|
||||
like via the `/chosen/module@<addr>/bootargs` node.
|
||||
@@ -25,6 +25,8 @@ Contents:
|
||||
usb
|
||||
ivshmem
|
||||
linuxboot
|
||||
generic-loader
|
||||
guest-loader
|
||||
vnc-security
|
||||
tls
|
||||
gdb
|
||||
|
||||
@@ -11,3 +11,11 @@ Download and uncompress a PC hard disk image with Linux installed (e.g.
|
||||
|qemu_system| linux.img
|
||||
|
||||
Linux should boot and give you a prompt.
|
||||
|
||||
Users should be aware the above example elides a lot of the complexity
|
||||
of setting up a VM with x86_64 specific defaults and assumes the
|
||||
first non switch argument is a PC compatible disk image with a boot
|
||||
sector. For a non-x86 system where we emulate a broad range of machine
|
||||
types, the command lines are generally more explicit in defining the
|
||||
machine and boot behaviour. You will find more example command lines
|
||||
in the :ref:`system-targets-ref` section of the manual.
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. _system-targets-ref:
|
||||
|
||||
QEMU System Emulator Targets
|
||||
============================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user