On Wednesday 12 December 2007 12:40:43 Anthony Liguori wrote:
Rusty Russell wrote:
On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
If QEMU ever got true SMP support, then virtio would not work as it
requires 16-bit atomic writes which AFAIK is not possible on a number of
On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
If QEMU ever got true SMP support, then virtio would not work as it
requires 16-bit atomic writes which AFAIK is not possible on a number of
non-x86 architectures.
Hmm? Where is this requirement coming from?
I think everyone should
Rusty Russell wrote:
On Sunday 09 December 2007 09:02:48 Anthony Liguori wrote:
If QEMU ever got true SMP support, then virtio would not work as it
requires 16-bit atomic writes which AFAIK is not possible on a number of
non-x86 architectures.
Hmm? Where is this requirement coming
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest. The ring queue is lock-less and depends on
the ability to atomically increment ring queue indices to be SMP safe.
Using a copy-API wouldn't be a problem for QEMU since the host and guest
are
Paul Brook wrote:
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest. The ring queue is lock-less and depends on
the ability to atomically increment ring queue indices to be SMP safe.
Using a copy-API wouldn't be a problem for QEMU since the
On 12/8/07, Paul Brook [EMAIL PROTECTED] wrote:
On Saturday 08 December 2007, Jamie Lokier wrote:
Paul Brook wrote:
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest. The ring queue is lock-less and depends on
the ability to
Paul Brook wrote:
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest. The ring queue is lock-less and depends on
the ability to atomically increment ring queue indices to be SMP safe.
Using a copy-API wouldn't be a problem for QEMU
Paul Brook wrote:
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest. The ring queue is lock-less and depends on
the ability to atomically increment ring queue indices to be SMP safe.
Using a copy-API wouldn't be a problem for QEMU since the host
Jamie Lokier wrote:
Paul Brook wrote:
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest. The ring queue is lock-less and depends on
the ability to atomically increment ring queue indices to be SMP safe.
Using a copy-API wouldn't be a problem
Anthony Liguori wrote:
virtio makes things a bit trickier though. There's a shared ring queue
between the host and guest.
Does this work when the host and guest are different architectures, or
different word sizes (x86/x86_64)?
-- Jamie
Actually according to qemu's standard, one should use
cpu_physical_memory_write/ cpu_physical_memory_read functions.
This is true also for reading the ring values.
Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
interfaces. We really don't want that for high speed I/O.
Dor Laor wrote:
Anthony Liguori wrote:
Index: qemu/hw/virtio-net.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/virtio-net.c2007-12-04 14:17:37.0 -0600
+
+static void virtio_net_receive(void
Paul Brook wrote:
Actually according to qemu's standard, one should use
cpu_physical_memory_write/ cpu_physical_memory_read functions.
This is true also for reading the ring values.
Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
interfaces. We really don't want that
Anthony Liguori wrote:
Index: qemu/hw/virtio-net.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ qemu/hw/virtio-net.c2007-12-04 14:17:37.0 -0600
+
+static void virtio_net_receive(void *opaque, const
14 matches
Mail list logo
