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: >> >>> On 15 October 2013 15:58, Tom Sutcliffe <tom.sutcliffe@xxxxxxxxxxx> wrote: >>>> Thumbs up from me testing on Arndale. My only issue is that virt and vexpress-a15 add virtio-mmio devices in the opposite order to each other, for the same set of -device command line arguments. It would avoid future headaches if we could have these behave the same. My preference would be for the virt behaviour, as the -device order matches the order in which the guest Linux kernel adds them to /dev (for virtio-blk-devices at least). >>> >>> 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 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. > I'll probably change QEMU anyway, just because if there's > no guarantee we might as well make qemu code do a simple > forwards loop rather than a backwards one. Sounds like the best option. Tom _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
