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

[John Williams]

On Mon, Jan 30, 2012 at 12:48 PM, Anthony Liguori <address@hidden> wrote:
>
> On Jan 29, 2012 8:41 PM, "John Williams" <address@hidden>
> wrote:
>>
>> >>>> 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.
>>
>> The machine state at bootup is very well defined - it's whatever the TRM
>> says!
>>
>> An example may help.  We are working on the Xilinx Zynq model, dual
>> core Cortex A-9.  We currently are able to use QEMU for the entire
>> flow from
>>
>> cold reset ->
>> bootrom ->
>> u-boot ->
>> Linux
>>
>> In this flow, we don't want any magic initial state, we want QEMU to
>> model the CPU just like the real hardware.
>>
>> Equivalently, we might like to kick directly into the kernel, SMP==2 and
>> so on.
>>
>> It makes no sense to me that we should somehow use a different machine
>> model just to model a different boot flow on the same hardware.
>>
>> Another example, we are working on remoteproc/rpmsg support so that we
>> can run Linux on one core, and firmware on another.  We have this
>> working in QEMU today, except we had to hack around the ARM boot
>> code's assumptions that we always want the 2nd CPU to run an WFE/WIQ
>> loop.  This is only true if you are running Linux *and* you want QEMU
>> to fake the actions of a bootloader.
>>
>> If you are modelling a cold start you want those two CPUs to race
>> until one of them reads the CPUID register puts itself to sleep, ie
>> just run the bootrom.
>>
>> All of these use cases are not about virtualisation, but about system
>> modeling and emulation, which really is where QEMU is valuable in the
>> embedded space.
>
> I don't see how any of this is relevant.  Presumably, on real hardware, you
> have a rom bank wired to a specific physical address with ip fixed to an
> address which happens to be in that space?

Certainly a ROM makes sense to model as a device - there is a physical
equivalent.  I'm just not so sure about a virtual device whos job is
to bus master stuffing contents into some other memory.  For example,
with such an 'ELF loader' device - when ecaxtly should it do the load?
 Do you end up with a race at system init time?

> Why not just use an emulated flash chip?

If there is a bus addressable memory with fixed contents then that can
be modelled with a device.  I'm talking about an intermediate mode
where we would like to be able to prepopulate memory with arbitrary
contents.  Half way between 'model a ROM device with the bootrom', and
the hacky 'QEMU is also sometimes a Linux bootloader' approach taken
for booting VMLinux images.

>> > 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.
>>
>> A network card is a tangible object, it can be present in the system.
>> The ELF loader is just emulator cruft, a necessary evil to get the
>> initial state of the machine.  Should it really be on a level footing
>> with actual devices?
>
> All systems have to bootstrap software some how.  Some device is reasonable
> for this.  This isn't emulated magic :-)

Sure.  I just have some questions about the behavioural semantics of
an ELF/binary loader device, vs recognising this loading function as a
role for a 'deus ex machina'

John
-- 
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663