Re: [Qemu-devel] [PATCH v7 0/3] hw/arm: Add 'virt' platform

[Peter Maydell]

On 17 October 2013 15:49, Tom Sutcliffe <address@hidden> wrote:
> On 17 Oct 2013, at 15:30, Peter Maydell <address@hidden> wrote:
>> On 15 October 2013 16:14, Tom Sutcliffe <address@hidden> wrote:
>>> On 15 Oct 2013, at 16:00, Peter Maydell <address@hidden> wrote:
>>>> Oh yes, I'd forgotten you mentioned that. Did anybody ever
>>>> track down *why* the kernel is reading the device tree
>>>> backwards?
>>>
>>> Not me :)

So I have figured this one out. libfdt seems to always
add new subnodes at the start of the parent node's list
of subnodes. This means that if you do "add A; add B; add C"
then the resulting device tree blob lists the nodes in
the order C B A. The kernel (and dtc in decompilation mode)
read the node list forwards, so they iterate through in
reverse order to how the nodes were added by the creator.

Peter, Andreas, David: do any of you know why libfdt does
this?

Anyway, as a result the bits of QEMU that generate device
trees for PPC boards specifically make sure they add
the nodes in reverse order in the places where order
of subnodes in the tree is important. So I think we should
follow suit for ARM boards, which means leaving vexpress
as it is and making mach-virt do them in reverse order too.

>> So apparently the kernel makes no guarantees at all about what
>> order it might process the virtio-mmio transports in. This
>> means that users mustn't rely on /dev/vda and /dev/vdb
>> corresponding to particular virtio-blk devices on QEMU's
>> command line -- you need to use UUIDs or something similar
>> instead.
>>
>> I think this sucks, but that's the kernel for you.
>
> Oh joy. One more thing to add to the How Long Before This
> Blows Up In My Face list. So long as it's consistent across
> multiple boots of a given kernel binary, I can probably live
> with it for the moment.

...and I will redirect anybody who complains about
the fact that vda and vdb are the "wrong way round"
to the kernel, because as it happens the kernel probes
the two virtio-mmio transports in the "right" order
(ie in the order they appear in the device tree blob),
it just ends up assigning vda and vdb in the opposite
order.

thanks
-- PMM