qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/8] virtio_get_byteswap: function for endian-am


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 1/8] virtio_get_byteswap: function for endian-ambivalent targets using virtio.
Date: Tue, 18 Feb 2014 17:11:19 +0200

On Tue, Feb 18, 2014 at 04:02:18PM +0100, Alexander Graf wrote:
> 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 <address@hidden>
> >>>
> >>>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 <address@hidden> ]
> >>>Signed-off-by: Rusty Russell <address@hidden>
> >>>Signed-off-by: Greg Kurz <address@hidden>
> >>>---
> >>>  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

1.0 won't use the flag, it's all LE.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]