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: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 1/8] virtio_get_byteswap: function for endian-ambivalent targets using virtio.
Date: Tue, 18 Feb 2014 16:02:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130910 Thunderbird/17.0.9

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




reply via email to

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