Am Freitag, 9. November 2007 schrieb Dor Laor:
I believe that the network interface will quickly go to the kernel since
copy takes most of the
cpu time and qemu does not support scatter gather dma at the moment.
Nevertheless using pio seems good enough, Anthony's suggestion of
notifying the
On Tuesday 20 November 2007, Avi Kivity wrote:
Sorry for being late in this thread.
We (s390) will need a hypercall as we do not have port I/O. I think it
should be
possible to default to hypercall on s390 and use pio everywhere else.
Or be generic: advertise the methods
Christian Borntraeger wrote:
Am Freitag, 9. November 2007 schrieb Dor Laor:
I believe that the network interface will quickly go to the kernel since
copy takes most of the
cpu time and qemu does not support scatter gather dma at the moment.
Nevertheless using pio seems good enough,
Anthony Liguori wrote:
Avi Kivity wrote:
There's no reason that the PIO operations couldn't be handled in the
kernel. You'll already need some level of cooperation in userspace
unless you plan on implementing the PCI bus in kernel space too.
It's easy enough in the pci_map function in
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
+case VIRTIO_PCI_QUEUE_NOTIFY:
+if (val VIRTIO_PCI_QUEUE_MAX)
+virtio_ring_kick(vdev, vdev-vq[val]);
+break;
I see you're not using hypercalls for this, presumably for compatibility
with
Avi Kivity wrote:
Anthony Liguori wrote:
+case VIRTIO_PCI_QUEUE_NOTIFY:
+if (val VIRTIO_PCI_QUEUE_MAX)
+virtio_ring_kick(vdev, vdev-vq[val]);
+break;
I see you're not using hypercalls for this, presumably for compatibility
with -no-kvm.
More than just
Anthony Liguori wrote:
+case VIRTIO_PCI_QUEUE_NOTIFY:
+if (val VIRTIO_PCI_QUEUE_MAX)
+virtio_ring_kick(vdev, vdev-vq[val]);
+break;
I see you're not using hypercalls for this, presumably for
compatibility
with -no-kvm.
More than just that. By stick to
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
+case VIRTIO_PCI_QUEUE_NOTIFY:
+if (val VIRTIO_PCI_QUEUE_MAX)
+virtio_ring_kick(vdev, vdev-vq[val]);
+break;
I
Avi Kivity wrote:
There's no reason that the PIO operations couldn't be handled in the
kernel. You'll already need some level of cooperation in userspace
unless you plan on implementing the PCI bus in kernel space too.
It's easy enough in the pci_map function in QEMU to just notify the
Anthony Liguori wrote:
This still needs quite a lot of work but I wanted to post it for reference.
Regards,
Anthony Liguori
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
...
Why change Rusty's codding standard? It will be harder to track changes.
+typedef struct VRingDesc
Dor Laor wrote:
Anthony Liguori wrote:
This still needs quite a lot of work but I wanted to post it for
reference.
Regards,
Anthony Liguori
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
...
Why change Rusty's codding standard? It will be harder to track changes.
Because
Avi Kivity wrote:
Anthony Liguori wrote:
+case VIRTIO_PCI_QUEUE_NOTIFY:
+if (val VIRTIO_PCI_QUEUE_MAX)
+virtio_ring_kick(vdev, vdev-vq[val]);
+break;
I see you're not using hypercalls for this, presumably for
compatibility
with -no-kvm.
More than just
Anthony Liguori wrote:
Avi Kivity wrote:
There's no reason that the PIO operations couldn't be handled in the
kernel. You'll already need some level of cooperation in userspace
unless you plan on implementing the PCI bus in kernel space too.
It's easy enough in the pci_map function in
Anthony Liguori wrote:
+case VIRTIO_PCI_QUEUE_NOTIFY:
+ if (val VIRTIO_PCI_QUEUE_MAX)
+ virtio_ring_kick(vdev, vdev-vq[val]);
+ break;
I see you're not using hypercalls for this, presumably for compatibility
with -no-kvm. Well I think I have a solution: advertise
14 matches
Mail list logo
