diff options
Diffstat (limited to 'results/classifier/118/all/808737')
| -rw-r--r-- | results/classifier/118/all/808737 | 155 |
1 files changed, 155 insertions, 0 deletions
diff --git a/results/classifier/118/all/808737 b/results/classifier/118/all/808737 new file mode 100644 index 000000000..d6c1d3c9e --- /dev/null +++ b/results/classifier/118/all/808737 @@ -0,0 +1,155 @@ +peripherals: 0.983 +debug: 0.975 +boot: 0.970 +permissions: 0.969 +semantic: 0.967 +register: 0.967 +architecture: 0.966 +kernel: 0.965 +arm: 0.962 +PID: 0.962 +device: 0.961 +socket: 0.958 +hypervisor: 0.957 +user-level: 0.956 +performance: 0.955 +assembly: 0.954 +ppc: 0.947 +risc-v: 0.943 +x86: 0.942 +vnc: 0.939 +graphic: 0.933 +files: 0.932 +TCG: 0.925 +VMM: 0.925 +virtual: 0.900 +mistranslation: 0.885 +network: 0.881 +KVM: 0.852 +i386: 0.496 + +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 + |