All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU
@ 2011-07-11 11:41 Anup Patel
  2011-07-11 13:25 ` Stefan Hajnoczi
                   ` (5 more replies)
  0 siblings, 6 replies; 9+ messages in thread
From: Anup Patel @ 2011-07-11 11:41 UTC (permalink / raw)
  To: qemu-devel

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737

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

Status in QEMU:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU
  2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
@ 2011-07-11 13:25 ` Stefan Hajnoczi
  2011-07-11 14:14 ` [Qemu-devel] [Bug 808737] " Anup Patel
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 9+ messages in thread
From: Stefan Hajnoczi @ 2011-07-11 13:25 UTC (permalink / raw)
  To: Bug 808737; +Cc: qemu-devel

On Mon, Jul 11, 2011 at 12:41 PM, Anup Patel <808737@bugs.launchpad.net> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
  2011-07-11 13:25 ` Stefan Hajnoczi
@ 2011-07-11 14:14 ` Anup Patel
  2011-07-11 15:23   ` Stefan Hajnoczi
  2011-07-11 14:17 ` Anup Patel
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 9+ messages in thread
From: Anup Patel @ 2011-07-11 14:14 UTC (permalink / raw)
  To: qemu-devel

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737

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

Status in QEMU:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
  2011-07-11 13:25 ` Stefan Hajnoczi
  2011-07-11 14:14 ` [Qemu-devel] [Bug 808737] " Anup Patel
@ 2011-07-11 14:17 ` Anup Patel
  2011-07-12  3:24 ` Anup Patel
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 9+ messages in thread
From: Anup Patel @ 2011-07-11 14:17 UTC (permalink / raw)
  To: qemu-devel

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737

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

Status in QEMU:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 14:14 ` [Qemu-devel] [Bug 808737] " Anup Patel
@ 2011-07-11 15:23   ` Stefan Hajnoczi
  2011-07-11 15:50     ` Peter Maydell
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan Hajnoczi @ 2011-07-11 15:23 UTC (permalink / raw)
  To: Bug 808737; +Cc: Peter Maydell, qemu-devel

On Mon, Jul 11, 2011 at 3:14 PM, Anup Patel <808737@bugs.launchpad.net> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 15:23   ` Stefan Hajnoczi
@ 2011-07-11 15:50     ` Peter Maydell
  0 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2011-07-11 15:50 UTC (permalink / raw)
  To: Stefan Hajnoczi; +Cc: qemu-devel, Bug 808737

On 11 July 2011 16:23, Stefan Hajnoczi <stefanha@gmail.com> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
                   ` (2 preceding siblings ...)
  2011-07-11 14:17 ` Anup Patel
@ 2011-07-12  3:24 ` Anup Patel
  2016-11-09 14:51 ` Thomas Huth
  2017-01-14  8:19 ` Thomas Huth
  5 siblings, 0 replies; 9+ messages in thread
From: Anup Patel @ 2011-07-12  3:24 UTC (permalink / raw)
  To: qemu-devel

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737

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

Status in QEMU:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
                   ` (3 preceding siblings ...)
  2011-07-12  3:24 ` Anup Patel
@ 2016-11-09 14:51 ` Thomas Huth
  2017-01-14  8:19 ` Thomas Huth
  5 siblings, 0 replies; 9+ messages in thread
From: Thomas Huth @ 2016-11-09 14:51 UTC (permalink / raw)
  To: qemu-devel

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

** Changed in: qemu
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737

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

Status in QEMU:
  Fix Committed

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Qemu-devel] [Bug 808737] Re: No option to load additional binary files from command line in QEMU
  2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
                   ` (4 preceding siblings ...)
  2016-11-09 14:51 ` Thomas Huth
@ 2017-01-14  8:19 ` Thomas Huth
  5 siblings, 0 replies; 9+ messages in thread
From: Thomas Huth @ 2017-01-14  8:19 UTC (permalink / raw)
  To: qemu-devel

Released with version 2.8

** Changed in: qemu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/808737

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

Status in QEMU:
  Fix Released

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/808737/+subscriptions

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-01-14  8:29 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-11 11:41 [Qemu-devel] [Bug 808737] [NEW] No option to load additional binary files from command line in QEMU Anup Patel
2011-07-11 13:25 ` Stefan Hajnoczi
2011-07-11 14:14 ` [Qemu-devel] [Bug 808737] " Anup Patel
2011-07-11 15:23   ` Stefan Hajnoczi
2011-07-11 15:50     ` Peter Maydell
2011-07-11 14:17 ` Anup Patel
2011-07-12  3:24 ` Anup Patel
2016-11-09 14:51 ` Thomas Huth
2017-01-14  8:19 ` Thomas Huth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.