From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34583)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1Vivlv-0002I6-4O
	for qemu-devel@nongnu.org; Tue, 19 Nov 2013 19:36:04 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1Vivlp-0006PR-PC
	for qemu-devel@nongnu.org; Tue, 19 Nov 2013 19:35:59 -0500
Received: from ozlabs.org ([203.10.76.45]:38458)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rusty@ozlabs.org>) id 1Vivlp-0006Oj-EZ
	for qemu-devel@nongnu.org; Tue, 19 Nov 2013 19:35:53 -0500
From: Rusty Russell <rusty@rustcorp.com.au>
In-Reply-To: <20131112124755.617e9755@oc7435384737.ibm.com>
References: <1381982022-19291-1-git-send-email-rusty@rustcorp.com.au>
	<20131112124755.617e9755@oc7435384737.ibm.com>
Date: Wed, 20 Nov 2013 10:29:53 +1030
Message-ID: <87siusc58m.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Qemu-devel] [PATCH 0/7] virtio endian-ambivalent target fixes.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Thomas Huth <thuth@linux.vnet.ibm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>, Cornelia Huck <cornelia.huck@de.ibm.com>, qemu-devel@nongnu.org

Thomas Huth <thuth@linux.vnet.ibm.com> writes:
> On Thu, 17 Oct 2013 14:23:35 +1030
> Rusty Russell <rusty@rustcorp.com.au> wrote:
>
>> This is a re-transmit of the core of the virtio endian code.  Since
>> there seems to be some interest in ARM BE virtio, I've separated this from
>> the direct problem I was solving: PowerPC LE.
>> 
>> Please apply!
>> Rusty.
>> 
>> Rusty Russell (7):
>>   virtio_get_byteswap: function for endian-ambivalent targets using
>>     virtio.
>>   virtio: allow byte swapping for vring and config access
>>   hw/net/virtio-net: use virtio wrappers to access headers.
>>   hw/net/virtio-balloon: use virtio wrappers to access page frame
>>     numbers.
>>   hw/block/virtio-blk: use virtio wrappers to access headers.
>>   hw/scsi/virtio-scsi: use virtio wrappers to access headers.
>>   hw/char/virtio-serial-bus: use virtio wrappers to access headers.
>
>  Hi Rusty!
>
> May I ask what's the current status of your virtio endian patches? We
> likely need something similar when we enable Virtio v1.0 for S390
> virtio-ccw since we then have to byteswap the virtio stuff there, too.
> So I recently started to have a look at this... However, in your
> patches, the byteswapping seems to be activated/disabled globally, with
> the "virtio_byteswap" variable. But with Virtio v1.0, the guest can
> decide on a per-device basis whether it wants to drive the device in
> v1.0 mode (--> byteswap on S390) or in v0.9 legacy mode (--> no
> byteswap), depending on whether it sets the VIRTIO_F_VERSION_1 feature
> bit or not. I guess other architectures will have the same problem with
> Virtio 1.0, too, when the guests are not running in little endian mode.
> So I wonder whether it would it be feasible to change the code so that
> the decision of byteswapping or not is done on a per-device basis
> instead? What do you think?

Hi Thomas,

        That is definitely the end-goal: these patches are simply to
enable current legacy virtio devices.

Since we missed 1.3, we're supposed to be in 2.0.

Cheers,
Rusty.