Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree

[Peter Maydell <peter.maydell@linaro.org>]

On Wed, 29 Sept 2021 at 04:01, Simon Glass <sjg@chromium.org> wrote:
> On Tue, 28 Sept 2021 at 03:21, Peter Maydell <peter.maydell@linaro.org> wrote:
> > So what *is* this patch doing? The subject says "Allow additions to
> > the generated device tree", and the patch adds an option to
> > "Merge a device tree binary (dtb) file into the generated device tree".
> > That sounds exactly like "combine two bits of dtb" -- the one the
> > user provides to the -dtbi option and the one QEMU generates
> > internally.
>
> Yes that's right, but as you say one of them is generated by QEMU. It
> is fixing a problem caused by QEMU's generation of the device tree,
> since it provides no wat to augment the device tree without my patch.

You can augment it in the guest if you need to add guest-specific stuff.

> > > The only current working option is to just pass the U-Boot dtb through
> > > and not use QEMU's on-the-fly-generated dtb at all. But I am assuming
> > > there is a reason why QEMU generates that dtb, so that would not be
> > > desirable?
> >
> > QEMU generates the dtb to tell the guest what hardware is
> > present and where it is. We don't guarantee that that hardware
> > arrangement is necessarily stable between QEMU versions (in
> > practice there are generally additions and not deletions or
> > moves, but in theory there might be). All the guest is supposed
> > to assume is the location of RAM and flash; everything else it
> > must look in the dtb to determine.
>
> Yes, so that is going to severely limit the usefulness of the virtio
> support, for example. But we can just ignore it for CI, I suppose,
> since we can use fixed parameters to QEMU, if you don't want to allow
> more control of the device tree.

virtio-mmio devices should already be correctly indicated in the
device tree. virtio-pci devices can be found by probing the PCI
bus in the usual way (and you can find out where the PCI controller
is by looking in the dtb).

> This patch is really just augmenting what QEMU is already doing and
> solving a problem that it has. I don't see it as creating a new boot
> mechanism or being a weird tweak. If anything, it puts the tweaking in
> the hands of the user. It seems like something you would be keen on,
> from that POV.

I absolutely see it as a weird tweak. It's something that
only u-boot seems to care about, and it's adding an extra
user-facing command line option that is basically
"if you need to boot u-boot you need this". The user should
not need to "control" the dtb, because QEMU should already
be creating a dtb which describes the hardware it is exposing
to the guest.

> > Guest software running on the "virt" board needs to know it is
> > running on the "virt" board and deal with the interface and
> > information that QEMU provides. (For instance, Arm Trusted
> > Firmware and UEFI both have done this.)
>
> Well unfortunately this is in conflict, based on what you have said in
> this thread. We can either have virtio support (use QEMU-generated
> device tree) or have U-Boot work correctly (use -dtb). Do you have any
> other ideas?

I've already suggested what I think you should do: have u-boot
combine the dtb it gets from QEMU with the dtb-extras stuff
it wants for its own purposes, with the latter supplied in
any of a bunch of workable ways (extra file loaded in memory,
concatenate the dtb blob with the u-boot binary at compile
time, whatever; rough analogy with however u-boot gets the
full dtb on hardware platforms where there is none).

-- PMM