No option to load additional binary files from command line in QEMU

[Anup Patel]

There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU.

[Stefan Hajnoczi (stefanha)]

On Mon, Jul 11, 2011 at 12:41 PM, Anup Patel <email address hidden> wrote:
> Public bug reported:
>
> There is no command line option like -kerner, or -initrd to load an
> arbitrary binary file to a RAM location when launching QEMU.

It depends on your target (e.g. qemu-system-x86_64) but you can load
your own code as a bzImage or multiboot binary. Both formats are
documented:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/x86/boot.txt
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html

The problem with loading binary code is that you quickly want some
options (is this real mode or protected mode code?, what address to
load at?, are there any modules/initrd extras elsewhere in memory?).
That's basically what multiboot is for.

Does multiboot do what you need? If not, please be more specific and
describe your target machine and use case.

Stefan

[Anup Patel (anup)]

I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my case I have to load hypervisor elf as kernel and there and number of other binaries like flattened device tree binary for hypervisor configuration, guest kernel binary, guest ramdisk, etc.

Currently, I am developing it for Realview PB-A8 board. For loading the above specified images I have to hack QEMU in hw/arm_boot.c, which is not a good solution.

In general, I will encounter similar problem for any other architecture too.

What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU.
(Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if)

I believe this option can be very handy for OS development and/or firmware development which require multiple binaries.

Do you think multiboot is suitable for scenario ??

--Anup

[Anup Patel (anup)]

Just to add to my use case.

Currently, to load a test binary called "arm_test.bin.patched" i have hacked QEMU in the following manner:

diff --git a/hw/arm_boot.c b/hw/arm_boot.c
index bfac982..e4873d4 100644
--- a/hw/arm_boot.c
+++ b/hw/arm_boot.c
@@ -280,6 +280,13 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info *info)
                                info->smp_loader_start);
         }
         info->initrd_size = initrd_size;
+ } else {
+ initrd_size = load_image_targphys("arm_test.bin", 0x100000, 0x1000000);
+ if (initrd_size < 0) {
+ fprintf(stderr, "qemu: could not load arm test code '%s'\n",
+ "arm_test.bin");
+ exit(1);
+ }
     }
     info->is_linux = is_linux;

--Anup

[Stefan Hajnoczi (stefanha)]

On Mon, Jul 11, 2011 at 3:14 PM, Anup Patel <email address hidden> wrote:
> I am trying to develop a lightweight hypervisor for ARM Cortex-A8. In my
> case I have to load hypervisor elf as kernel and there and number of
> other binaries like flattened device tree binary for hypervisor
> configuration, guest kernel binary, guest ramdisk, etc.
>
> Currently, I am developing it for Realview PB-A8 board. For loading the
> above specified images I have to hack QEMU in hw/arm_boot.c, which is
> not a good solution.
>
> In general, I will encounter similar problem for any other architecture
> too.
>
> What I wish is that can QEMU have an command option to load a binary file to a physical location after system initialization is done and before QEMU starts emulating a virtual CPU.
> (Note: the command line option will be concerned with physical address and not virtual address so in case of x86_64 it does not matter if)
>
> I believe this option can be very handy for OS development and/or
> firmware development which require multiple binaries.
>
> Do you think multiboot is suitable for scenario ??

Doesn't arm_boot.c already load an arbitrary binary when the image is
neither a kernel ELF or uboot image? I don't know the arm_boot.c
details but skimming the source shows it already does
load_image_targphys().

Stefan

[Peter Maydell (pmaydell)]

On 11 July 2011 16:23, Stefan Hajnoczi <email address hidden> wrote:
> Doesn't arm_boot.c already load an arbitrary binary when the image is
> neither a kernel ELF or uboot image?  I don't know the arm_boot.c
> details but skimming the source shows it already does
> load_image_targphys().

The assumption is that an ELF image is a random raw binary,
and a non-ELF image is an actual kernel. I hate this and
would much rather we had a more generic way of saying "look,
just load this ELF file into physical memory please" (and
that -kernel always treated its argument as an actual kernel,
but that would break backwards compatibility :-()

-- PMM

[Anup Patel (anup)]

I understand that we should not change -kernel option for backwards compatibility, that's why I suggest some new option for loading arbitrary binary file (not necessarily ELF file). This option would just mean: "Just blindly load the given file to the given physical address". We can also pass this options multiple times in command line to load different files.

I don't know if such an option would create problems in any other part of QEMU. Is it possible to have such an option in QEMU ?

This problem has been bugging me since a year now so, it will be a great help if we can have it.

Thanks,
--Anup

[Thomas Huth (th-huth)]

I think this problem should be fixed with the new generic loader device:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e481a1f6

[Thomas Huth (th-huth)]

Released with version 2.8