Re: [Qemu-devel] address order of virtio-mmio devices

[Laszlo Ersek]

On 01/29/15 20:09, Richard W.M. Jones wrote:
> On Thu, Jan 29, 2015 at 07:29:09PM +0100, Laszlo Ersek wrote:
>> On 01/29/15 19:15, Peter Maydell wrote:
>>> On 29 January 2015 at 17:25, Laszlo Ersek <address@hidden> wrote:
>>>> I find that virtio-mmio devices are assigned highest-to-lowest addresses
>>>> as they are found on the command line. IOW, this code (from commit
>>>> f5fdcd6e):
>>>>
>>>>     /* Note that we have to create the transports in forwards order
>>>>      * so that command line devices are inserted lowest address first,
>>>>      * and then add dtb nodes in reverse order so that they appear in
>>>>      * the finished device tree lowest address first.
>>>>      */
>>>>     for (i = 0; i < NUM_VIRTIO_TRANSPORTS; i++) {
>>>>         int irq = vbi->irqmap[VIRT_MMIO] + i;
>>>>         hwaddr base = vbi->memmap[VIRT_MMIO].base + i * size;
>>>>
>>>>         sysbus_create_simple("virtio-mmio", base, pic[irq]);
>>>>     }
>>>>
>>>> works exactly in reverse.
>>>
>>> Note that you can't rely on device ordering anyway. Guests
>>> should be using UUIDs or similar to ensure they mount the
>>> right filesystems in the right places, because the kernel
>>> makes no guarantee that it will enumerate devices in the
>>> device tree in any particular order.
>>
>> Understood. Then we'll probably have to address this in libguestfs.
> 
> That's pretty much impossible.  If we can't fix qemu, then libguestfs
> will need to add the drives in reverse order on the command line (for
> this case virtio-blk && -M virt).

That's precisely what I meant by "addressing it in libguestfs". My idea
wasn't reversing the drives but to fixup the root=.... kernel cmdline
parameter. But I didn't look into it at all; I certainly defer to you.

> I should note that we're only trying to use virtio-blk because
> virtio-scsi is broken

It's not directly virtio-scsi that's broken; something in the thread
pool breaks on aarch64 KVM, and only virtio-scsi exposes it, virtio-blk
doesn't (although it uses the same thread pool, just with fewer middle
layers).

> ...  Laszlo: is there a public bug for that?

There isn't.

I requested permission on the appropriate internal list to open up bug
1184405. I didn't get permission. I disagree with that to this day
(given the actual contents of the bug).

Paolo had suggested to use Launchpad, but I resisted (for good reason;
Launchpad is possibly the worst bug tracker imaginable. I have specific
reasons.)

Working 12+ hours per day I don't feel the slightest inclination to
screw around with substandard bug trackers during the original research,
nor to shovel over 30+ carefully edited comments and about 10
attachments after their initial record in the RHBZ. The way forward is
to open up 1184405, if we'd like it to be public.

Thanks
Laszlo