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

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/29/2012 08:19 PM, John Williams wrote:
> On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> On 01/29/2012 06:28 PM, John Williams wrote:
>>>
>>> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
>>> <peter.crosthwaite@petalogix.com>    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 file@address
>>
>>
>> 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