Re: [Qemu-devel] [PATCH 1/8] virtio_get_byteswap: function for endian-ambivalent targets using virtio.

[Alexander Graf <agraf@suse.de>]

On 02/18/2014 04:03 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 18, 2014 at 03:48:38PM +0100, Alexander Graf wrote:
>> On 02/18/2014 01:38 PM, Greg Kurz wrote:
>>> From: Rusty Russell <rusty@rustcorp.com.au>
>>>
>>> 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.  Meanwhile, create a hook for
>>> little endian ppc (and potentially ARM).  This is called at device
>>> reset time (which is done before any driver is loaded) since it
>>> may involve a system call to get the status when running under kvm.
>>>
>>> [ fixed checkpatch.pl error with the virtio_byteswap initialisation,
>>>    ldq_phys() API change, Greg Kurz <gkurz@linux.vnet.ibm.com> ]
>>> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>>> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
>>> ---
>>>   hw/virtio/virtio.c                |    6 ++
>>>   include/hw/virtio/virtio-access.h |  132 +++++++++++++++++++++++++++++++++++++
>>>   include/hw/virtio/virtio.h        |    2 +
>>>   stubs/Makefile.objs               |    1
>>>   stubs/virtio_get_byteswap.c       |    6 ++
>>>   5 files changed, 147 insertions(+)
>>>   create mode 100644 include/hw/virtio/virtio-access.h
>>>   create mode 100644 stubs/virtio_get_byteswap.c
>>>
>>> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
>>> index aeabf3a..4fd6ac2 100644
>>> --- a/hw/virtio/virtio.c
>>> +++ b/hw/virtio/virtio.c
>>> @@ -19,6 +19,9 @@
>>>   #include "hw/virtio/virtio.h"
>>>   #include "qemu/atomic.h"
>>>   #include "hw/virtio/virtio-bus.h"
>>> +#include "hw/virtio/virtio-access.h"
>>> +
>>> +bool virtio_byteswap;
>> Could this be a virtio object property rather than a global? Imagine
>> an AMP guest system with a BE and an LE system running in parallel
>> accessing two separate virtio devices. With a single global that
>> would break.
>>
>>
>> Alex
> Well, how does a device know which CPU uses it?
> I suspect we are better off waiting for 1.0 with this one.

Good point. It just feels like a heavy layering violation to have a 
global variable for all virtio devices. What if we start mixing legacy 
and 1.0 devices? We could reuse the same flag, but it would be 
initialized differently per device.


Alex