From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxZ11-0000XV-So for qemu-devel@nongnu.org; Thu, 19 Jun 2014 05:52:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxZ0v-0005on-Gk for qemu-devel@nongnu.org; Thu, 19 Jun 2014 05:52:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4878) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxZ0v-0005oQ-80 for qemu-devel@nongnu.org; Thu, 19 Jun 2014 05:52:13 -0400 Date: Thu, 19 Jun 2014 17:51:57 +0800 From: Stefan Hajnoczi Message-ID: <20140619095157.GC2766@stefanha-thinkpad.redhat.com> References: <20140613111703.22108.14322.stgit@bahia.local> <20140617073631.GL16768@stefanha-thinkpad.redhat.com> <539FF0E3.6040407@suse.de> <20140618103814.GG14030@stefanha-thinkpad.redhat.com> <20140618143521.3941fd4f@bahia.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline In-Reply-To: <20140618143521.3941fd4f@bahia.local> 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: Greg Kurz Cc: Kevin Wolf , Peter Maydell , rusty@ozlabs.au.ibm.com, "Michael S. Tsirkin" , Stefan Hajnoczi , Rusty Russell , Alexander Graf , qemu-devel@nongnu.org, Juan Quintela , aneesh.kumar@linux.vnet.ibm.com, Anthony Liguori , Amit Shah , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 18, 2014 at 02:35:21PM +0200, Greg Kurz wrote: > On Wed, 18 Jun 2014 18:38:14 +0800 > Stefan Hajnoczi wrote: >=20 > > On Tue, Jun 17, 2014 at 09:40:19AM +0200, Alexander Graf wrote: > > >=20 > > > 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, rem= arks from > > > >>ppc64 dump support review (yes, we talked about virtio there) and t= he work on > > > >>virtio subsections migration. Also two new patches have been added: > > > >>- patch #1 is a preliminary fix for virtio-serial posted by Alexand= er 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 endianne= ss > > > >depend on the CPUState through which the device is being accessed. > > > > > > > >Can you explain why it's necessary to check the CPUState? > > >=20 > > > 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 :). > >=20 > > What bothers me is that real hardware can't do this. Given that VIRTIO > > 1.0 is always little-endian I guess this is just a temporary hack for > > ppc little-endian. Would be nice to add a comment so it's clear why > > this approach is being taken instead of a cleaner solution. > >=20 > > Stefan >=20 > Hi Stefan, >=20 > Previous versions of this patch set had such comments: >=20 > "virtio data structures are defined as "target endian", which assumes > that's a fixed value. In fact, that actually means it's platform-specifi= c. > The OASIS virtio 1.0 spec will fix this, by making all little endian. >=20 > We need to support both implementations and we want to share as much code > as possible." >=20 > but these lines got lost between v6 and v7... my bad... :-\ Thanks! I just wasn't mentally prepared when looking through the patch series, the comment puts it into context. Stefan --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTorK9AAoJEJykq7OBq3PIH8IIAJgyyBZul11Kqrf9swXPfHHX JzSSfp0OJfAHsxB67d1DeT0VcQSi6JG4AgDbGx/gRY1mHTKK1gAqIwjeM0QfdAIB H8E18UQs5x/aFRFLT8nLUZ2iyIakud0AU4WKwG+UouY103Ar018r2p0NTMX2/smZ sS6eQT6Xr1SGr7a0wW8pfIe8wrLUYPxjewqNnikAnq0dpjWMv7XNxGQUrnCEtZ1B 0b1EuSHr7THIRG8zcW7xvh2vFntAQzyF5fONkzPEO1tr48kjUwuRimMxOpY8adWv vv/FTFDHVJRYncrA/cxrmkt50k7B/tZzNyZuu3118LUt7B1bl4nPwOQovVYkrjM= =9jSq -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4--