From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwo0L-00055Z-3M for qemu-devel@nongnu.org; Tue, 17 Jun 2014 03:40:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wwo0D-0005jz-Jf for qemu-devel@nongnu.org; Tue, 17 Jun 2014 03:40:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52667 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wwo0D-0005js-DZ for qemu-devel@nongnu.org; Tue, 17 Jun 2014 03:40:21 -0400 Message-ID: <539FF0E3.6040407@suse.de> Date: Tue, 17 Jun 2014 09:40:19 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20140613111703.22108.14322.stgit@bahia.local> <20140617073631.GL16768@stefanha-thinkpad.redhat.com> In-Reply-To: <20140617073631.GL16768@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Stefan Hajnoczi , Greg Kurz Cc: Kevin Wolf , Peter Maydell , "Michael S. Tsirkin" , Rusty Russell , qemu-devel@nongnu.org, Juan Quintela , aneesh.kumar@linux.vnet.ibm.com, Anthony Liguori , Amit Shah , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 17.06.14 09:36, Stefan Hajnoczi wrote: > On Fri, Jun 13, 2014 at 01:18:00PM +0200, Greg Kurz wrote: >> This version merges the changes requested during the v7 review, remarks from >> ppc64 dump support review (yes, we talked about virtio there) and the work on >> virtio subsections migration. Also two new patches have been added: >> - patch #1 is a preliminary fix for virtio-serial posted by Alexander Graf >> - patch #9 prepares the work on the virtio_is_big_endian() helper >> >> The most significant changes are: >> - introduction of a new CPU method for virtio >> - endianness is taken from CPU that resets the device >> - fastpath virtio memory accessors for fixed endian targets >> - VMState based virtio subsections (compatibility friendly) > I'm surprised it's not enough for the virtio device to have an > endianness field (big/little). It seems these patches make endianness > depend on the CPUState through which the device is being accessed. > > Can you explain why it's necessary to check the CPUState? They only check CPUState at the point in time of reset, as that's the only case where we can derive the implicit endian configuration from :). After reset, endianness is a simple field in the state struct. Alex