Arnd Bergmann wrote:
> Not sure if I'm following the reasoning here. Shouldn't the method be
> inherent to the virtio bus driver?
>
> When you use a PCI based virtio bus, the natural choice would be PIO
> in some way, but you could also have a different virtio implementation
> on PCI that uses hca
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
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 enou
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
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 fu
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 tra
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 VRin
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 QEM
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
>
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
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
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
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 see you're not using hyperc
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
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.
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: advert
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
index 65f449e..3032337 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -448,6 +448,8 @@ VL_OBJS += rtl8139.o
# PCI Hyperc
17 matches
Mail list logo
