qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 5/7] vl.c: added -kerndtb option


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC PATCH 5/7] vl.c: added -kerndtb option
Date: Sun, 29 Jan 2012 20:28:30 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

On 01/29/2012 08:19 PM, John Williams wrote:
On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori<address@hidden>  wrote:
On 01/29/2012 06:28 PM, John Williams wrote:

On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
<address@hidden>    wrote:

Hi All,

So on the topic of these command line arguments for initrd, dtb and
friends,
another related issue we have encountered (and have hacked around in our
tree) is not being able to relocate the initrd or kernel. Currently these
memory locations are hardcoded in arm_boot.c:

#define KERNEL_ARGS_ADDR 0x100
#define KERNEL_LOAD_ADDR 0x00010000
#define INITRD_LOAD_ADDR 0x00d00000

If you see patch 6/7 in this same series I put in place a hack to
override
the initrd location in memory, but I wonder if instead this should go up
to
the command line interface as a parameter. Currently the machine model
(or
arm_boot.c) defines exactly where kernels/initrds/command-line-args line
in
memory, but since these are software properties should perhaps they go up
to
the command line as -kernel,foo=bar options? E.G:

qemu-system-arm

-kernel,kernel-image=/foo/zImage,kernel-addr=0x00010000,initrd=/foo/initrd,initrd_addr=0x00d00000


There's an opportunity here - QEMU needs the cmdline ability to load
random binaries/elfs anyway, such as

--load address@hidden


Make an elf loader device if you desire this ability but I'm skeptical that
it really is all that useful.

It is useful for non-Linux use-cases, of which there are many!

It's not just a matter of loading an elf binary in memory. You probably need to have a specific register state set in order to run non-Linux elf binaries which means you'll need binary specific logic.

If all of these binaries you want to run have a well known register state, they you can just use fw_cfg and a piece of firmware to read the binary (which is basically how -kernel works on target-i386).


Can you explain how you'd see such a 'loader device' in practice?  How
does it get bound into the machine model?  How do we pass arguments to
it?

You create a device via qdev (now QOM) that takes whatever properties you need. You then do:

-device elf-loader,base=0xa00000,file=my-elf-binary

No different than adding a network card.

As I mentioned in the previous note, we probably should short cut unknown options as just assume they're meant for -device such that you could also do:

-elf-loader base=0xa00000,file=my-elf-binary

Regards,

Anthony Liguori


Thanks,

John




reply via email to

[Prev in Thread] Current Thread [Next in Thread]