diff options
Diffstat (limited to 'results/classifier/108/debug/808737')
| -rw-r--r-- | results/classifier/108/debug/808737 | 140 |
1 files changed, 0 insertions, 140 deletions
diff --git a/results/classifier/108/debug/808737 b/results/classifier/108/debug/808737 deleted file mode 100644 index b527cdba..00000000 --- a/results/classifier/108/debug/808737 +++ /dev/null @@ -1,140 +0,0 @@ -debug: 0.975 -boot: 0.970 -permissions: 0.969 -semantic: 0.967 -other: 0.965 -PID: 0.962 -device: 0.961 -socket: 0.958 -performance: 0.955 -vnc: 0.939 -graphic: 0.933 -files: 0.932 -network: 0.881 -KVM: 0.852 - -No option to load additional binary files from command line in QEMU - -There is no command line option like -kerner, or -initrd to load an arbitrary binary file to a RAM location when launching QEMU. - -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 - - -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 - -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 - -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 - - -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 - - -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 - -I think this problem should be fixed with the new generic loader device: -http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e481a1f6 - -Released with version 2.8 - |