Re: [Qemu-devel] What events should be handled in iohandler context?

[Stefan Hajnoczi]

On Mon, Jul 15, 2019 at 06:19:31PM +0300, Anton Kuchin wrote:
> I'm trying to understand contexts and handlers/notifiers and a bit confused
> about two contexts living in main loop: qemu_aio_context and iohandler_ctx.
> It is mentioned in the iohandler_ctx comment that qemu_aio_context can't be
> reused because "iohandlers mustn't be polled by aio_poll(qemu_aio_context)"
> but there is no exlanation why.

It's a historic thing that existing code depends on.  Users of the
iohandlers API do not expect their fds to be processed when
aio_poll(qemu_aio_context) is called.

New code tends to use qemu_aio_context because the AioContext API can
also be used with IOThreads.  This means processing can run in the main
loop thread or a dedicated thread (IOThread) without code changes.

> I tried to find examples and failed to understand why virtio-net eventfds
> are registred to iohandler_ctx with generic virtio callback
> virtio_device_start_ioeventfd_impl() but TX bottom-half and handlers of
> back-end TAP use qemu_aio_context.
> 
> Can you explain a little bit why we need some fds to be polled and some not
> to be polled? And how can I choose which context is right for me?

By default hw/virtio/virtio.c uses iohandler_ctx although devices can
use virtio_queue_aio_set_host_notifier_handler() to attach the
host_notifier to any AioContext.  virtio-blk and virtio-scsi are
examples of doing with with an IOThread.

The iohandler_ctx vs qemu_aio_context separation is a conservative way
of maintaining assumptions in existing code.  There might be code that
can safely run in qemu_aio_context instead, but it can be hard to
foresee issues caused by switching so it only be done if there is a good
reason.

Stefan

signature.asc
Description: PGP signature