|  | .. | 
|  | 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 its | 
|  | 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 its 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 its 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. |