From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9EvM-0001r6-5i for qemu-devel@nongnu.org; Tue, 13 Aug 2013 09:46:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9EvD-0003xa-NN for qemu-devel@nongnu.org; Tue, 13 Aug 2013 09:46:12 -0400 Received: from mail-ee0-x235.google.com ([2a00:1450:4013:c00::235]:47390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9EvD-0003xN-HQ for qemu-devel@nongnu.org; Tue, 13 Aug 2013 09:46:03 -0400 Received: by mail-ee0-f53.google.com with SMTP id b15so4255562eek.12 for ; Tue, 13 Aug 2013 06:46:02 -0700 (PDT) Date: Tue, 13 Aug 2013 15:45:59 +0200 From: Stefan Hajnoczi Message-ID: <20130813134559.GA29990@stefanha-thinkpad.redhat.com> References: <5209E6A1.6060308@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5209E6A1.6060308@siemens.com> Subject: Re: [Qemu-devel] Using aio_poll for timer carrier threads List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , qemu-devel , liu ping fan , Alex Bligh , Paolo Bonzini , MORITA Kazutaka , Richard Henderson 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