Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Peter Maydell]

On 12 November 2014 16:25, Paolo Bonzini <address@hidden> 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