On Mon, Jan 30, 2012 at 12:48 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > > On Jan 29, 2012 8:41 PM, "John Williams" <john.willi...@petalogix.com> > wrote: >> >> >>>> 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. >> >> 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
