From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pawel Moll Subject: Re: [PATCH 0/3] virtio-mmio: handle BE guests on LE hosts Date: Mon, 14 Oct 2013 10:04:55 +0100 Message-ID: <1381741495.3247.18.camel@hornet> References: <1381502171-8187-1-git-send-email-marc.zyngier@arm.com> <20131012182837.GC2089@redhat.com> <525BAA40.8070103@arm.com> <20131014085931.GB30954@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marc Zyngier , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , Rusty Russell To: "Michael S. Tsirkin" Return-path: Received: from service87.mimecast.com ([91.220.42.44]:52000 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754485Ab3JNJE7 convert rfc822-to-8bit (ORCPT ); Mon, 14 Oct 2013 05:04:59 -0400 In-Reply-To: <20131014085931.GB30954@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2013-10-14 at 09:59 +0100, Michael S. Tsirkin wrote: > On Mon, Oct 14, 2013 at 09:24:32AM +0100, Marc Zyngier wrote: > > Hi Michael, > >=20 > > On 12/10/13 19:28, Michael S. Tsirkin wrote: > > > On Fri, Oct 11, 2013 at 03:36:08PM +0100, Marc Zyngier wrote: > > >> This small patch series adds just enough kernel infrastructure a= nd > > >> fixes to allow a BE guest to use virtio-mmio on a LE host, provi= ded > > >> that the host actually supports such madness. > > >> > > >> This has been tested on arm64, with some fixes to KVM and a set = of > > >> changes to kvmtool, both which I am posting separately. > > >> > > >> A branch containing all the relevant changes is at: > > >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.= git kvm-arm64/be-on-le-3.12-rc4 > > >> > > >> Cc: Rusty Russell > > >> Cc: Michael S. Tsirkin > > >> Cc: Pawel Moll > > >=20 > > > We are changing the spec to make everything LE instead of > > > the native endian. > > >=20 > > > I think that'll fix the issue in a cleaner way. > >=20 > > While I agree that it would solve the issue completely, it would al= so > > break all BE users. Is that really an option? >=20 > I proposed several ways to create "transitional devices" > which can detect and switch to old interface at run-time. >=20 > Pawel thinks that's not necessary so ... Don't wipe yourself with my name, please. You forgot to mention that the devices are versioned and the behavior o= f the legacy devices remains unchanged. No existing implementation will b= e broken. Pawe=C5=82