From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yxmtt-00059M-By for qemu-devel@nongnu.org; Wed, 27 May 2015 21:46:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yxmts-0005H8-CQ for qemu-devel@nongnu.org; Wed, 27 May 2015 21:46:25 -0400 Date: Thu, 28 May 2015 09:46:15 +0800 From: Fam Zheng Message-ID: <20150528014615.GA22609@dhcp-14-238.nay.redhat.com> References: <1432711146-28405-1-git-send-email-famz@redhat.com> <556590B1.2040405@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556590B1.2040405@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 0/4] aio: Don't poll ioeventfd in nested aio_poll() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , qemu-block@nongnu.org, "Michael S. Tsirkin" , Stefan Weil , qemu-devel@nongnu.org, Stefan Hajnoczi On Wed, 05/27 11:38, Paolo Bonzini wrote: > > > On 27/05/2015 09:19, Fam Zheng wrote: > > This series looks at the other side of the broken "qmp transaction" problem > > with dataplane [1] - the event loop. > > > > Before, an ioeventfd of a non-dataplane device is registered via > > qemu_set_fd_handler, which is only polled directly by main_loop_wait(), not in > > aio_poll(); an ioeventfd of a dataplane device (virtio-blk/virtio-scsi) is > > registered specially via aio_set_event_notifier, which is a wrapper of > > aio_set_fd_handler, thus it WILL be polled by all aio_poll(). > > > > As explained in [1], and in patch 3, this is wrong. The handlers mustn't run. > > > > [1] Fixes it by unregistering them temporarily around such nested poll, while > > this series fixes it by skipping those file descriptors in all nested > > aio_poll(), just like how iohandler behaves in the main loop. > > > > On the one hand, it is simpler than [1]; on the other hand, this approach is > > also interesting because once we remove qemu_set_fd_handler2 [2], iohandler.c > > can be removed by converting all qemu_set_fd_handler to the new > > aio_set_io_event_notifier introduced in this series. > > I don't think this can work. > > Whenever the main context is doing synchronous work for dataplane, it is > in the outermost aio_poll. > You're right. :( The main context uses iohandler and aio_dispatch, neither calls aio_set_dispatching(). However, if we have [2], they can be changed to aio_poll(), then would this idea work? Fam