Re: [PATCH 00/27] hw/arm: Add generic FDT-based machine and infrastructure

["Alex Bennée" <alex.bennee@linaro.org>]

Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:

> On Tue, Jan 27, 2026 at 11:03 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Mon, 26 Jan 2026 at 17:43, Ruslan Ruslichenko
>> <ruslichenko.r@gmail.com> wrote:
>> >
>> > From: Ruslan Ruslichenko <Ruslan_Ruslichenko@epam.com>
>> >
>> > This patch series introduces new ARM machine model, arm-generic-fdt, and the underlying infrastructure required to instantiate a QEMU machine from a Device Tree.
>>
>> I'm afraid this has been a feature that has been suggested from
>> time to time, but which I don't think is workable in general.
>>
>> Device tree files are designed to provide enough information to
>> the guest kernel to allow it to find non-probeable hardware. They
>> are not designed to provide enough information to QEMU to allow
>> it to create and wire up all the hardware present on the system.
>>
>> There are specific niches where it can be made to work -- I think
>> Xilinx have or had a setup where they were generating an FPGA
>> model and a device tree and a guest kernel all from the same
>> single data source, so they could put everything necessary into
>> the dtb, for example -- but I don't think it works in the
>> general case. As one simple example, the DTB doesn't generally
>> have any information about how the Secure world works in an Arm
>> system, because Linux doesn't care about the Secure world. It
>> also doesn't usually have information that the guest OS can
>> probe for itself at runtime.
>>
>> There has been periodic discussion of more flexible user-driven
>> board creation, but that has generally been with the idea of using
>> the QMP monitor to orchestrate creation and connection of device
>> models.
>>
> I agree that a guest Device Tree is insufficient for describing a
> complete QEMU machine model.
> However, we separate the guest configuration from the machine
> definition. The -hw-dtb option allows the user to provide a
> QEMU-specific system description.
> Those hw-dtb would not be passed to Linux Guest VM.
>
> The fact that this workflow has been successfully used in production
> by AMD/Xilinx demonstrates that FDT is a feasible format.

Where are the extensions to the FDT used for hw-dtb documented? How does
it deal with PCI devices and the Secure world?

> In contrast, QMP usage may end up even more complex and less
> maintainable for the task of full system modeling.
> To my understanding, this would need to generate too long configs,
> which may eventually require some intermediate format by itself.
>
> I am proposing to use FDT as a serialization format to describe a
> machine configuration. Theoretically we can use other formats, like
> XML, but in my opinion FDT perfectly matches the requirements.

The QMP interface is self-documenting and introspectable and used for
the management of QEMU including things like hotplug. It is also QOM
aware so a natural fit for dealing with the underlying QOM machinery.

Previous discussions have entertained the idea of making the parsing of
hw-dtb an external script which would then translate into QMP commands
to build up the machine.

>
> BR,
> Ruslan Ruslichenko
>
>
>> thanks
>> -- PMM

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro