From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHZE-0005ZW-9k for qemu-devel@nongnu.org; Wed, 18 Jun 2014 11:14:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxHZ5-00045a-Ra for qemu-devel@nongnu.org; Wed, 18 Jun 2014 11:14:28 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54810 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxHZ5-00045T-Gw for qemu-devel@nongnu.org; Wed, 18 Jun 2014 11:14:19 -0400 Message-ID: <53A1ACC9.2080305@suse.de> Date: Wed, 18 Jun 2014 17:14:17 +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> <20140618143521.3941fd4f@bahia.local> <20140618151249.GA1697@redhat.com> In-Reply-To: <20140618151249.GA1697@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: "Michael S. Tsirkin" , Greg Kurz Cc: Kevin Wolf , Peter Maydell , Anthony Liguori , Juan Quintela , Stefan Hajnoczi , Rusty Russell , qemu-devel@nongnu.org, aneesh.kumar@linux.vnet.ibm.com, Stefan Hajnoczi , Amit Shah , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 18.06.14 17:12, Michael S. Tsirkin wrote: > 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: >> >>> On Tue, Jun 17, 2014 at 09:40:19AM +0200, Alexander Graf wrote: >>>> 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 :). >>> 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. >>> >>> Stefan >> Hi Stefan, >> >> Previous versions of this patch set had such comments: >> >> "virtio data structures are defined as "target endian", which assumes >> that's a fixed value. In fact, that actually means it's platform-specific. >> The OASIS virtio 1.0 spec will fix this, by making all little endian. >> >> We need to support both implementations and we want to share as much code >> as possible." >> >> but these lines got lost between v6 and v7... my bad... :-\ >> >> I agree all of this is a hack but: >> - it has been on the table for nearly a year >> - ppc LE distros are already available >> - the memory accessors part makes sense for 1.0 >> >> and, speaking of 1.0, I couldn't find any clue about when QEMU would support >> this (Cc'ing Rusty for his input), but we (IBM and distro partners) need >> ppc LE support now. >> >> Cheers. > QEMU 2.2 I think. > > One disadvantage of this work is that it removes some of the stimulus > for people to work on 1.0, replacing it with hacks. Hmm. If you prefer I can also apply these patches and send a pull request for them. Alex