From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH8dB-0003Em-FN for qemu-devel@nongnu.org; Fri, 30 Jan 2015 05:16:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH8d8-00074Y-8V for qemu-devel@nongnu.org; Fri, 30 Jan 2015 05:16:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH8d8-00074N-0o for qemu-devel@nongnu.org; Fri, 30 Jan 2015 05:16:50 -0500 Message-ID: <54CB5A0B.5060908@redhat.com> Date: Fri, 30 Jan 2015 11:16:43 +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> In-Reply-To: <20150130095456.GB27572@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: Wei Huang , qemu devel list On 01/30/15 10:54, Daniel P. Berrange wrote: > On Thu, Jan 29, 2015 at 08:05:50PM +0000, Peter Maydell wrote: >> On 29 January 2015 at 19:47, Laszlo Ersek wrote: >>> On 01/29/15 20:12, Laszlo Ersek wrote: >>>> If the guest kernel changed its "assignment strategy" at some point, but >>>> earlier it used to match the comment (and the code), then whichever way >>>> we shape the comment will be wrong for the other kernel strategy. :) So, >>>> in that case this code is probably best left undisturbed. >>>> >>>> I'll try to dig out some kernel commit for more evidence. >>> >>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70161ff3 >> >> Thanks for digging that up -- I was half-thinking we might >> just have got it wrong two years ago when we wrote the code :-) >> >> We should probably update the comment to say (a) what we were >> trying to do (b) that we don't want to change it now because >> it would break existing setups. > > 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. > > Also can we start using a versioned machine type for ARM, and make the > new machine type have the correct ordering for current kernels. Wei recently posted a patch that introduced versioning for machvirt. (I didn't see the patch, only know about it.) If Peter agrees, I guess both Wei's patch and mine could be applied. (Although, mine should be reworked so that it affect only the new machtype.) Thanks Laszlo