From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHvu-000660-Rg for qemu-devel@nongnu.org; Wed, 18 Jun 2014 11:38:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxHvm-0004Md-V2 for qemu-devel@nongnu.org; Wed, 18 Jun 2014 11:37:54 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55303 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHvm-0004MX-PY for qemu-devel@nongnu.org; Wed, 18 Jun 2014 11:37:46 -0400 Message-ID: <53A1B248.7020007@suse.de> Date: Wed, 18 Jun 2014 17:37:44 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20140613111703.22108.14322.stgit@bahia.local> <20140617073631.GL16768@stefanha-thinkpad.redhat.com> <539FF0E3.6040407@suse.de> <20140618103814.GG14030@stefanha-thinkpad.redhat.com> <20140618134204.GB31764@redhat.com> <20140618162804.6e2cb399@bahia.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 00/20] virtio endian-ambivalent target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Greg Kurz Cc: Kevin Wolf , Anthony Liguori , "Michael S. Tsirkin" , Stefan Hajnoczi , Rusty Russell , QEMU Developers , Juan Quintela , "Aneesh Kumar K.V" , Stefan Hajnoczi , Amit Shah , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 18.06.14 17:35, Peter Maydell wrote: > On 18 June 2014 15:28, Greg Kurz wrote: >> On Wed, 18 Jun 2014 16:42:04 +0300 >> "Michael S. Tsirkin" wrote: >>> On Wed, Jun 18, 2014 at 01:53:15PM +0100, Peter Maydell wrote: >>>> On 18 June 2014 11:38, Stefan Hajnoczi wrote: >>>>> What bothers me is that real hardware can't do this. >>>> Real hardware doesn't have "endianness matches guest CPU endianness" >>>> semantics, which is what the virtio spec mandates... >>> So it was buggy. We never thought anyone would do a cross endian CPU :(. >>> We are fixing it in 1.0. >>> >> virtio isn't the only victim... we also have vga. The problem can pop up >> anywhere you rely on TARGET_WORDS_BIGENDIAN. > No, relying on TARGET_WORDS_BIGENDIAN is fine. It's only > a problem if your guest somehow assumes that messing with > the CPU state changes the behaviour of devices as a random > side effect. That's true for virtio. I'm pushing that it should not > be true for VGA (ie that the guest should have to explicitly tell > the VGA device "be the other endian now"). It's also not true for > most average devices whose endianness is > TARGET_WORDS_BIGENDIAN -- it just means they don't > change behaviour, and if the guest wants to be BE on a > fundamentally LE hardware device it gets to do the byte > swapping... I actually agree with Greg here. We implicitly create different VGA adapters today depending on TARGET_WORDS_BIGENDIAN. The FB endianness should have been separate devices (BE / LE) or runtime configuration from the beginning. Anything that checks TARGET_WORDS_BIGENDIAN in hw/ is very likely to do something pretty wrong ;). Alex