Thomas Huth <th...@linux.vnet.ibm.com> writes:
> On Thu, 17 Oct 2013 14:23:35 +1030
> Rusty Russell <ru...@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.
