From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGus9-00011R-NT for qemu-devel@nongnu.org; Thu, 29 Jan 2015 14:35:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGus6-0007HQ-HR for qemu-devel@nongnu.org; Thu, 29 Jan 2015 14:35:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGus6-0007HL-A4 for qemu-devel@nongnu.org; Thu, 29 Jan 2015 14:35:22 -0500 Message-ID: <54CA8B74.3010706@redhat.com> Date: Thu, 29 Jan 2015 20:35:16 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <54CA6CF6.7090308@redhat.com> <54CA7BF5.8020800@redhat.com> <20150129190912.GB3860@redhat.com> In-Reply-To: <20150129190912.GB3860@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] address order of virtio-mmio devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: Peter Maydell , qemu devel list 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 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