| 1 | .. |
| 2 | Copyright (c) 2020, Linaro |
| 3 | |
| 4 | Guest Loader |
| 5 | ------------ |
| 6 | |
| 7 | The guest loader is similar to the ``generic-loader`` although it is |
| 8 | aimed at a particular use case of loading hypervisor guests. This is |
| 9 | useful for debugging hypervisors without having to jump through the |
| 10 | hoops of firmware and boot-loaders. |
| 11 | |
| 12 | The guest loader does two things: |
| 13 | |
| 14 | - load blobs (kernels and initial ram disks) into memory |
| 15 | - sets platform FDT data so hypervisors can find and boot them |
| 16 | |
| 17 | This is what is typically done by a boot-loader like grub using its |
| 18 | multi-boot capability. A typical example would look like: |
| 19 | |
| 20 | .. parsed-literal:: |
| 21 | |
| 22 | |qemu_system| -kernel ~/xen.git/xen/xen \ |
| 23 | -append "dom0_mem=1G,max:1G loglvl=all guest_loglvl=all" \ |
| 24 | -device guest-loader,addr=0x42000000,kernel=Image,bootargs="root=/dev/sda2 ro console=hvc0 earlyprintk=xen" \ |
| 25 | -device guest-loader,addr=0x47000000,initrd=rootfs.cpio |
| 26 | |
| 27 | In the above example the Xen hypervisor is loaded by the -kernel |
| 28 | parameter and passed its boot arguments via -append. The Dom0 guest |
| 29 | is loaded into the areas of memory. Each blob will get |
| 30 | ``/chosen/module@<addr>`` entry in the FDT to indicate its location and |
| 31 | size. Additional information can be passed with by using additional |
| 32 | arguments. |
| 33 | |
| 34 | Currently the only supported machines which use FDT data to boot are |
| 35 | the Arm and RiscV ``virt`` machines. |
| 36 | |
| 37 | Arguments |
| 38 | ^^^^^^^^^ |
| 39 | |
| 40 | The full syntax of the guest-loader is:: |
| 41 | |
| 42 | -device guest-loader,addr=<addr>[,kernel=<file>,[bootargs=<args>]][,initrd=<file>] |
| 43 | |
| 44 | ``addr=<addr>`` |
| 45 | This is mandatory and indicates the start address of the blob. |
| 46 | |
| 47 | ``kernel|initrd=<file>`` |
| 48 | Indicates the filename of the kernel or initrd blob. Both blobs will |
| 49 | have the "multiboot,module" compatibility string as well as |
| 50 | "multiboot,kernel" or "multiboot,ramdisk" as appropriate. |
| 51 | |
| 52 | ``bootargs=<args>`` |
| 53 | This is an optional field for kernel blobs which will pass command |
| 54 | like via the ``/chosen/module@<addr>/bootargs`` node. |