From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH9uM-0003JE-1F for qemu-devel@nongnu.org; Fri, 30 Jan 2015 06:38:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH9uG-0008Sr-QJ for qemu-devel@nongnu.org; Fri, 30 Jan 2015 06:38:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH9uG-0008Sj-Iv for qemu-devel@nongnu.org; Fri, 30 Jan 2015 06:38:36 -0500 Message-ID: <54CB6D36.9070305@redhat.com> Date: Fri, 30 Jan 2015 12:38:30 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <54CA6CF6.7090308@redhat.com> <54CA7BF5.8020800@redhat.com> <54CA8637.2080306@redhat.com> <54CA8E37.8070009@redhat.com> <20150130095456.GB27572@redhat.com> <20150130104833.GC27572@redhat.com> In-Reply-To: <20150130104833.GC27572@redhat.com> Content-Type: text/plain; charset=utf-8 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: "Daniel P. Berrange" , Peter Maydell Cc: qemu devel list On 01/30/15 11:48, Daniel P. Berrange wrote: > On Fri, Jan 30, 2015 at 10:29:46AM +0000, Peter Maydell wrote: >> On 30 January 2015 at 09:54, Daniel P. Berrange wrote: >>> While it is clear there is no solution that works correctly with all >>> kernels, I hate to think that we're going to stick with an ordering >>> that is clearly wrong for modern kernels, forever going forward. The >>> aarch64 world is only just starting out, so on balance I think we >>> should optimize for the future rather than the past, since that gives >>> right behaviour for orders of magnitude more people in the long term. >> >> Yeah, I agree it's awkward. But I hate breaking people's >> working setups, and we have no guarantee the kernel won't >> change again in the future. >> >> You could try asking the kernel folk to revert that patch on >> the basis that it breaks things... > > Might be worth a shot - the patch is only a month old. Or at least do a > followup patch to put the ordering back the way it was, rather than plain > revert Please note that (as far as I understand) the patch that I referenced is indeed very new, it's not part of v3.18, but the reversal can easily be seen with v3.18. In other words, the kernel patch I referenced introduces no functional change, it just reorganizes stuff in the kernel (AIUI), with the benefit of killing a superfluous field. The reason I referenced it because its *commit message* gives good background. If we really wanted to find the kernel change that reversed the traversal, we'd have to talk to Grant and/or bisect the kernel. Thanks Laszlo > Long term though it will be much better of AArch64 would just do PCI > instead of MMIO bus. Then we have proper device addressing which we > can control in a predictable manner that will be stable across hotplug > and unplug and migration. I hear there's work on PCI for AArch64 but > is there a near term ETA yet ? > > Regards, > Daniel >