[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] What events should be handled in iohandler context?
Date: Fri, 19 Jul 2019 10:40:46 +0100
User-agent: Mutt/1.12.0 (2019-05-25)

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


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]