From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH8I5-0004oQ-QF for qemu-devel@nongnu.org; Fri, 30 Jan 2015 04:55:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YH8I2-0008E2-3j for qemu-devel@nongnu.org; Fri, 30 Jan 2015 04:55:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YH8I1-0008D5-SR for qemu-devel@nongnu.org; Fri, 30 Jan 2015 04:55:02 -0500 Date: Fri, 30 Jan 2015 09:54:56 +0000 From: "Daniel P. Berrange" Message-ID: <20150130095456.GB27572@redhat.com> References: <54CA6CF6.7090308@redhat.com> <54CA7BF5.8020800@redhat.com> <54CA8637.2080306@redhat.com> <54CA8E37.8070009@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] address order of virtio-mmio devices Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Laszlo Ersek , qemu devel list 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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|