On 12 November 2014 16:25, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 12/11/2014 17:13, Arnd Bergmann wrote: >> > Same as real hardware. Firmware (SeaBIOS or OVMF) builds the memory >> > map, decides where in the free space the BARs go, and programs the PCI >> > devices accordingly. >> > >> > kvmtool is the special one here. Xen, VMware, Hyper-V all do the same >> > as QEMU. >> >> Right. I guess embedded ARM images in qemu are a third way then, because >> these don't have a guest firmware but also don't set up the hardware >> the way that kvmtool does. >> >> Claudio's request to do this differently on arm64 seems absolutely >> reasonable to me, but I guess that implies having UEFI or something >> like it that does the PCI scan. Not sure what the best default for >> "qemu -kernel image" should be though if you don't explicitly pass >> a firmware image. > > The PowerPC folks are using u-boot as the firmware. I know Peter > disagrees, but I don't understand why so I'll throw this up for > discussion too; it is definitely lighter-weight than UEFI. Would that > make sense for ARM?
I don't have any objection to people running u-boot firmware if that's what makes sense for them. Historically QEMU's -kernel option on ARM has behaved as "do the extremely bare minimum that the ARM kernel boot protocol demands, as by-hand setup of the CPU before we start executing". Before the advent of multiprocessor this was pretty much just "set up an ATAGS list and then boot the kernel by setting a couple of registers and jumping to it". Bringing in SMP and then the GIC and now device trees has gradually increased the scope of the little bootloader that's built into QEMU, and it is showing the strains a little (especially now it has to cope with some tweaks for some board/SoC models where their SMP secondary boot protocol is different). TrustZone is probably going to complicate the picture further. Anyway, this approach works because ARMv7 embedded Linux doesn't really demand much of its bootloader. It has the advantage that we haven't needed to carry around ROM images for all our board models (which are a pain to deal with since you get to pick between needing a target CPU toolchain for building, or distributing binary blobs; and in some cases they aren't redistributable at all unless you go to the effort of writing custom firmware just for QEMU). Unlike x86, we wouldn't be able to just have one firmware and be done with it. ARMv8 Linux at the moment also has a pretty minimal set of booting requirements (the kernel does not require anything like setting up PCI BARs, for instance), and so we've taken a similar approach with the addition of implementing the PSCI firmware interface for CPU power up/down/reset. You could make a pretty good argument that the QEMU builtin bootloader really has reached the end of its useful life and we should switch to always booting some lump of firmware. (Indeed, the VM spec for ARMv8 mandates a UEFI firmware.) But for any particular new feature in the past we've ended up taking the pragmatic approach of adding it to the builtin loader rather than committing to replacing the whole thing. If ARMv8 Linux starts mandating PCI setup and other complicated setup then the balance probably tilts towards running at least some firmware in all cases. -- PMM
