On 17 October 2013 15:49, Tom Sutcliffe <tom.sutcliffe@xxxxxxxxxxx> wrote: > On 17 Oct 2013, at 15:30, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >> On 15 October 2013 16:14, Tom Sutcliffe <tom.sutcliffe@xxxxxxxxxxx> wrote: >>> On 15 Oct 2013, at 16:00, Peter Maydell <peter.maydell@xxxxxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
