Re: [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest

[Anthony Liguori <anthony@codemonkey.ws>]

Gerd Hoffmann <kraxel@redhat.com> writes:

>   Hi,
>
>>>> and is also a good
>>>> reason why exposing this information via a common interface (fw_cfg)
>>>> would be a good idea.
>>>
>>> Huh?  As far I know we generate device trees in qemu instead of
>>> expecting pseries firmware compile them from fw_cfg information.
>> 
>> It depends on what firmware you are using.
>
> Of course.  On archs which don't use device trees in the first place it
> doesn't make sense.
>
>> We don't really generate device trees in general in QEMU.
>
> pseries does (thats why the hard libfdt dependency if you want pseries
> support).  arm wants move into that direction too.

pseries is a bad example because it's not a real hardware platform.
It's emulating what PowerVM does.  It's more akin to the xenpv machine
than a real piece of hardware.

>
>> As Peter mentioned, in an ideal world we'd generate them from the QOM
>> graph.
>
> Sure.
>
>> That should happen in the firmware and it could be enabled by
>> adding just a couple fw_cfg commands to navigate the QOM graph (analogs
>> to qom-list and qom-get in QMP).
>
> I don't think Peter intended to imply *that* ...

Yes, this has been discussed dozens of times in the past.  And as I've
said in the past, generating device trees belongs in the firmware.  It's
a firmware/OS interface.

It's not just an academic argument though.  We want to expose hardware
interfaces that are rich enough for firmware to do whatever it needs to
do to initialize the system.  There are a lot of things that are
normally only visible to firmware that we don't emulate today.

In exposing this information, we ought to attempt to do so in an
architectural neutral way.

ACPI is not architectural neutral.  You could argue that that's okay
because we only need to support two things: ACPI and device trees.  But
that's not quite right.

Device trees very often have platform specific quirks so a generated
device tree in common code is not going to have the right set of quirks
for any given system.

Having a good interface for firmware to generate ACPI tables and device
trees solves this problem in a much nicer way.  It enables firmware to
display whatever type of tree it wants (ACPI or device tree) and also
provides the flexibility to implement the necessary quirks for that
platform.

Regards,

Anthony Liguori

>
> cheers,
>   Gerd