Re: [Qemu-devel] Using aio_poll for timer carrier threads

[Stefan Hajnoczi <stefanha@gmail.com>]

On Tue, Aug 13, 2013 at 09:56:17AM +0200, Jan Kiszka wrote:
> in the attempt to use Alex' ppoll-based timer rework for decoupled,
> real-time capable timer device models I'm now scratching my head over
> the aio_poll interface. I'm looking at dataplane/virtio-blk.c, just finding
> 
> static void *data_plane_thread(void *opaque)
> {
>     VirtIOBlockDataPlane *s = opaque;
> 
>     do {
>         aio_poll(s->ctx, true);
>     } while (!s->stopping || s->num_reqs > 0);
>     return NULL;
> }
> 
> wondering where the locking is. Or doesn't this use need any at all? Are
> all data structures that this thread accesses exclusively used by it, or
> are they all accessed in a lock-less way?

Most of the data structures in dataplane upstream are not shared.
Virtio, virtio-blk, and Linux AIO raw file I/O are duplicated for
dataplane and do not rely on QEMU infrastructure.

I've been working on undoing this duplication over the past months but
upstream QEMU still mostly does not share data structures and therefore
does not need much synchronization.  For the crude synchronization that
we do need we simply start/stop the dataplane thread.

> Our iothread mainloop more or less open-codes aio_poll and is, thus,
> able to drop its lock before falling asleep while still holding it
> during event dispatching. Obviously, I need the same when processing
> timer lists of an AioContext, protecting them against concurrent
> modifications over VCPUs or other threads. So I'm thinking of adding a
> block notification callback to aio_poll, to be called before/after
> qemu_poll_ns so that any locks can be dropped / reacquired as needed. Or
> am I missing some magic interface / pattern?

Upstream dataplane does not use timers, so the code there cannot serve
as an example.

If you combine Alex Bligh, Ping Fan, and my latest timer series, you get
support for QEMUTimer in AioContexts where qemu_timer_mod_ns() and
qemu_timer_del() are thread-safe.  vm_clock (without icount) and
rt_clock are thread-safe clock sources.

This should make timers usable in another thread for clock device
emulation if only your iothread uses the AioContext and its timers
(besides the thread-safe mod/del interfaces).

The details depend on your device, do you have a git repo I can look at
to understand your device model?

Stefan