Re: [Qemu-devel] edk2 submodule + binaries (Re: [PATCH V5 2/7] tests/acpi: add pxb/pxb-pcie tests)

[Laszlo Ersek]

On 07/19/16 12:05, Gerd Hoffmann wrote:
>   Hi,
> 
>>>  (4) What about ArmVirtPkg for 32bit arm?
>>
>> I think this would be a good idea.
> 
>> We should be aiming to get 'virt' to work for the 32-bit case.
>> vexpress-a9/a15 is trying to model real hardware and has a
>> lot of irritating constraints as a result (like no PCI, only
>> SD card storage).
>>
>> This probably means sorting out passing through the DTB
>> from QEMU into UEFI and then into the boot loader.

Yes, the piece that is missing is that the boot loader should be capable
of looking up the UEFI sysconfig table with the well-known GUID that
exposes the DTB.

(NB: such a sysconfig table is not *required* by any means, especially
not on aarch64. It is valid for the firmware to not expose any DTB to
stuff that comes after it, in an "ACPI only" configuration.)

... Actually, I'm getting confused about this. I just suggested that the
boot loader look up the right UEFI sysconfig table. But, if the boot
loader is already UEFI capable, why does it need the DTB at all? Gerd
named the virtio-mmio nodes in the DTB, but now I don't see how they are
relevant -- the boot loader should just use the UEFI services to load
and start the OS. Why does it need to know about virtio-mmio at all?

> Looking at aarch64 it looks like the guest kernel doesn't use acpi but
> got a fdt somehow.  Dunno how that happened.

The aarch64 upstream kernel (to my knowledge) defaults to DTB, unless it
gets "acpi=force" on the command line, or ArmVirtQemu is built with -D
PURE_ACPI_BOOT_ENABLE" (in which case the kernel will have no DTB to
look at, only ACPI).

>  I guess ArmVirtPkg exports
> the FDT using EFI interfaces,

Yes (unless built with "-D PURE_ACPI_BOOT_ENABLE").

> then either the kernel gets it directly

The DTB is installed as a UEFI sysconfig table with a well-known GUID.
All guest code that can look up UEFI sysconfig tables can locate and
read it.

> or
> grub is able to get and pass on the FDT.  In any case it seems think the
> same should work for 32bit without too much trouble.

It should be possible, but as I said, now I'm doubting that grub should
be involved in this at all.

First, the DTB reaches the kernel, from the firmware, without any
assitance from grub, through the sysconfig table.

Second, grub should not need the DTB for its own purposes *at all* -- a
boot loader on a UEFI system should use UEFI services only, for booting
the OS. The DTB might be necessary for low-level hardware drivers, I
guess, but in a UEFI guest, grub should not use low-level hw drivers.

... I mean, this is how grub already works in x86_64 and aarch64 UEFI
guests. I think we're sitting on the horse backwards. DTB has probably
been a "last resort" for 32-bit ARM GRUB, because there used to be no
UEFI, hence no UEFI services, hence only the DTB allowed GRUB to do
something with the hardware

But now that there *is* UEFI for 32-bit ARM (guests, anyway), the
bootloader should not use UEFI only as a means to fetch the DTB, and
then do whatever it's been doing earlier. Instead, UEFI should be used
to boot the OS.

Thanks
Laszlo