[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on V
From: |
Marcelo Tosatti |
Subject: |
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY |
Date: |
Mon, 22 Feb 2010 12:16:02 -0300 |
User-agent: |
Mutt/1.5.20 (2009-08-17) |
On Mon, Feb 22, 2010 at 04:51:46PM +0200, Avi Kivity wrote:
> On 02/22/2010 04:29 PM, Marcelo Tosatti wrote:
> >On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote:
> >>On 02/22/2010 03:59 PM, Marcelo Tosatti wrote:
> >>>VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers,
> >>>so wakeup the iothread to process that information immediately.
> >>>
> >>>Reported-by: Amit Shah<address@hidden>
> >>>Signed-off-by: Marcelo Tosatti<address@hidden>
> >>>
> >>>Index: qemu/hw/virtio-pci.c
> >>>===================================================================
> >>>--- qemu.orig/hw/virtio-pci.c
> >>>+++ qemu/hw/virtio-pci.c
> >>>@@ -204,6 +204,7 @@ static void virtio_ioport_write(void *op
> >>> break;
> >>> case VIRTIO_PCI_QUEUE_NOTIFY:
> >>> virtio_queue_notify(vdev, val);
> >>>+ qemu_notify_event();
> >>> break;
> >>virtio_queue_notify() will call ->handle_output(), which should
> >>either do what's needed to be done, or wake up some iothread itself.
> >kick is used to inform either output processing, in which case
> >->handle_output() does what its supposed to.
> >
> >But its also used to inform availability of new buffers, which is common
> >to all virtio devices. So what is the point pushing this to
> >->handle_output?
>
> I don't understand what this means. ->handle_output() _is_
> informing the device model of new buffers. What more is needed?
>
> >Are you concerned about spurious wakeups?
>
> Yes. Also, qemu_notify_event() is an undirected notification (wakes
> up all iothreads, and all devices), whereas ->handle_output() is
> directed (wakes up exactly what is needed).
>
> What's the underlying problem? A new input buffer has become
> available, and we need to re-poll the incoming file descriptor? If
> so, that's best done from ->handle_output() (either by waking the
> iothread or calling read() itself and perhaps receiving -EAGAIN).
Yes. Sure, perhaps calling read() itself is appropriate, and i see
your point that >handle_output contains more context for a smarter
decision.
But one can argue thats an improvement on top of a dumb wakeup.
- [Qemu-devel] [patch uq/master 0/2] wake iothread on virtio kick / flush_coalesced_mmio smp_wmb, Marcelo Tosatti, 2010/02/22
- [Qemu-devel] [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Marcelo Tosatti, 2010/02/22
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Avi Kivity, 2010/02/22
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Marcelo Tosatti, 2010/02/22
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Avi Kivity, 2010/02/22
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY,
Marcelo Tosatti <=
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Anthony Liguori, 2010/02/22
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Avi Kivity, 2010/02/22
- [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Anthony Liguori, 2010/02/22
- Re: [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY, Avi Kivity, 2010/02/22
[Qemu-devel] [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio, Marcelo Tosatti, 2010/02/22