When ARM moves into the server market, we will no longer rely on boot-loaders like U-Boot loading a device tree to the kernel. However, both Xen and KVM have been built relying on providing FDTs to guests (including Dom0 on Xen).  When hardware starts booting Linux using ACPI and without any device tree available, both Xen and KVM needs to support that.

For KVM, the problem is limited to QEMU being able to generate a ACPI for VMs or potentially we need to run firmware inside the VM that can generate ACPI tables for the guest kernel being loaded.

Xen has a very similar case for DomUs, but the Dom0 case is slightly more complicated.

The reason is that the actual device drivers for the hardware run in Dom0 and Dom0 therefore needs access to the original ACPI tables from the firmware.  However, the Xen hypervisor is booted before Dom0 and the hypervisor itself will use some of the available device (serial port, GIC, timers).  Therefore, Xen needs to be able to modify the firmware data structure to present a view to Dom0 that works with mainline kernels for Dom0.

Fundamentally we need to choose between: (1) presenting modified ACPI tables to Dom0, (2) presenting FDT to the guest regardless of the data structure used to boot the hypervisor, and (3) be able to both (1) and (2).

There are challenges in all approaches and this session sees to present the latest concensus from the community in the matter and ensures that there is agreement between kernel people, firmware people, and KVM and Xen developers. 

Link to Hangout video: or

Link to Hangout event:

Link to Etherpad:



Speakers (1)

Who's Attending (50)

See all