Gerd Hoffmann <kra...@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
