Re: Can OVMF run on an emulated QEMU ARM vexpress-a9?

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 12 June 2017 at 18:28, Laszlo Ersek <lersek@redhat.com> wrote:
> CC Ard & Leif
>

Thanks Laszlo

> On 06/12/17 08:44, Andre wrote:
>> Hi,
>>
>> this might be a silly question, as I am learning as I go about the topic,
>> but is it possible to emulate UEFI on QEMU when setting the emulated
>> machine to an ARM vexpress-a9?
>>

No. The mach-virt UEFI firmware expects a DT description at the base
of DRAM, which QEMU only provided for mach-virt. Also, 'base of DRAM'
could be anything on an ARM system,.

>> I was able to emulate it on QEMU's virt machine, but I don't care as much
>> about the vexpress-a9, but as to know whether OVMF can only run against
>> QEMU's virt machine or if it can run against some other emulated board.
>>
>> Are there too many differences between the virt machine to other boards
>> that make providing images for different emulated boards impractical?
>>

Yes. The mach-virt firmware uses DT, but most ARM ports are fully
hardcoded. I.e., the MMIO address of every peripheral, timer
interrupts, base and size of memory etc etc are all decided at build
time.

>> I really don't know enough even to know if my question is sensible, so any
>> pointers on the topic are really appreciated!
>
> Your question is fully justified and to the point.
>
> The answer is that, yes, there's a *whole lot* of integration between
> QEMU machine type and firmware. This is reflected by several things:
>
> - The kinds of firmware drivers we include the firmware build follows
> the QEMU machine type. Under "driver", understand both software drivers
> (i.e. something that produces ACPI tables and SMBIOS tables -- because
> QEMU exports those in a particular format), and hardware drivers (for
> the kinds of emulated hardware that we know the targeted QEMU machine
> type will, or can, provide).
>
> - The way we customize or control generic (= platform-independent)
> firmware drivers.
>
> - The things we assume about hardware in the lowest-level / earliest
> firmware modules (for example, what parts of the address space are known
> to map to system RAM / MMIO / platform devices; what IO ports belong to
> what platform devices, etc)
>
> There *is* a bunch of stuff we try to abstract even between QEMU and
> firmware, for enabling incremental development & compat, but then again
> those abstractions rest upon virtual hardware specifics (DTB pre-filled
> into RAM, fw_cfg, virtio, ...).
>
> So, a quick summary about virtual platform support (that I know of) in edk2:
>
> - ArmVirtPkg/ArmVirtQemu.dsc:
>
>   - qemu-system-arm and qemu-system-aarch64, with the "virt" machine
>     type (the higher-versioned "virt" machine types you use, the better
>     integration you get)
>
> - ArmVirtPkg/ArmVirtQemuKernel.dsc:
>
>   - Not really sure about the QEMU configuration for this, but see
>     commit 8de84d424221 ("ArmVirtPkg: implement ArmVirtQemuKernel",
>     2016-02-05) for the intended use. I think Ard can explain it better.
>

The standard mach-virt machine you get when using -bios boots with the
firmware image exposed as an emulated XIP NOR flash. Many ARM systems
that boot with ARM trusted firmware don't run UEFI in place but load
it into DRAM and execute it from there.

So ArmVirtQemuKernel runs from DRAM instead. It borrows the Linux
kernel boot protocol to achieve this, since it was already implemented
by QEMU via -kernel (and -bios/-pflash omitted)

> - ArmVirtPkg/ArmVirtXen.dsc:
>
>   - Xen, with HVM (fullvirt) guests, potentially using the XenPV block
>     device. Both arm/aarch64. (I'm not a Xen user myself, hence the
>     scant details -- I'm sorry.)
>
> - OvmfPkg/*dsc:
>
>   - qemu-system-i386 and qemu-system-x86_64, with the "pc" and "q35"
>     machine types (the higher-versioned machine types you use, the
>     better integration you get)
>
>   - Xen, with HVM (fullvirt) guests, potentially using the XenPV block
>     device
>
> There used to be ArmPlatformPkg/ArmVExpressPkg (now defunct I think?),
> and there's
> <https://git.linaro.org/uefi/OpenPlatformPkg.git/tree/Platforms/ARM/VExpress>
> as well.
>

We have support for a couple of ARM reference platforms, but I don't
think VExpress A9 is among those anymore.

> I think the latter might just give you what you want.
>
> You might get away running builds of existent firmware platforms (DSC
> files) in non-matching environments, but the platform integration will
> suffer. This ranges from "crashes without a single log message" to "some
> optional UEFI protocols are missing".
>

In general, this is something more likely to achieve the latter on
x86, given that 'x86 architecture' usually means 'PC platform', which
are uniform enough to at least get some output on a serial port.

On ARM, platforms are so disparate that there is really no point in
trying to experiment with non-matching firmware unless you have some a
priori reason to believe the platforms are sufficiently similar