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

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

[Andre]

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?

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?

I really don't know enough even to know if my question is sensible, so any
pointers on the topic are really appreciated!

Thank you,
Andre

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

[Laszlo Ersek]

CC Ard & Leif

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?
> 
> 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?
> 
> 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.

- 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.

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".

Thanks
Laszlo

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

[Ard Biesheuvel]

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

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

[Laszlo Ersek]

(side track)

On 06/12/17 18:40, Ard Biesheuvel wrote:
> On 12 June 2017 at 18:28, Laszlo Ersek <lersek@redhat.com> wrote:

>> - 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)

Ah! So you boot that firmware binary itself with the "-kernel" option;
is that right?

(I guess I'll finally understand why you called the DSC file
"ArmVirtQemuKernel" :) )

Thanks!
Laszlo

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

[Ard Biesheuvel]

> On 12 Jun 2017, at 21:38, Laszlo Ersek <lersek@redhat.com> wrote:
> 
> (side track)
> 
>> On 06/12/17 18:40, Ard Biesheuvel wrote:
>> On 12 June 2017 at 18:28, Laszlo Ersek <lersek@redhat.com> wrote:
> 
>>> - 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)
> 
> Ah! So you boot that firmware binary itself with the "-kernel" option;
> is that right?
> 
> (I guess I'll finally understand why you called the DSC file
> "ArmVirtQemuKernel" :) )
> 
> 

Yes :-)

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

[Leif Lindholm]

On Mon, Jun 12, 2017 at 06:28:45PM +0200, Laszlo Ersek wrote:
> There used to be ArmPlatformPkg/ArmVExpressPkg (now defunct I think?),

Not quite defunct, just partially migrated to (and used by) the below.

> and there's
> <https://git.linaro.org/uefi/OpenPlatformPkg.git/tree/Platforms/ARM/VExpress>
> as well.
> 
> I think the latter might just give you what you want.

There would probably be some effort required, creating .dsc/.fdf files
- but the vast majority of code should be available. The only 32-bit
platform still supported is "TC2", described by ArmVExpress-CTA15-A7.dsc.

Depending on exactly how much the qemu vexpress-a9 platform models,
and how, some development and/or code archeology may be required.
vexpress-a15 could actually be a lot less effort, since the cortex-a15
contains only architectural caches, whereas the cortex-a9 hardware
platforms used an external L2 (PL310).

If someone would be keen enough to provide an ARM Trusted Firmware
port for CortexA9x4, I would be happy to resurrect that platform port.
But I wouldn't want to bring back the "start from EL3" version.

> 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".

Indeed.

/
    Leif