From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agBDt-0000VI-H6 for qemu-devel@nongnu.org; Wed, 16 Mar 2016 09:10:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agBDp-0003b4-I3 for qemu-devel@nongnu.org; Wed, 16 Mar 2016 09:10:49 -0400 References: <1458123018-18651-1-git-send-email-famz@redhat.com> <56E9355A.5070700@redhat.com> <56E93A22.1080102@de.ibm.com> <56E93ECE.10103@redhat.com> <20160316123213.3dcf0abc.cornelia.huck@de.ibm.com> <56E94806.7060505@redhat.com> <20160316125623.38ab4c7e.cornelia.huck@de.ibm.com> <56E94AA9.8000803@redhat.com> <20160316132212.674f766f.cornelia.huck@de.ibm.com> <56E9527B.9010001@redhat.com> <20160316134257.72d7da56.cornelia.huck@de.ibm.com> <56E95646.8020802@redhat.com> <20160316140458.44dcd97d.cornelia.huck@de.ibm.com> From: Paolo Bonzini Message-ID: <56E95B45.7060807@redhat.com> Date: Wed, 16 Mar 2016 14:10:29 +0100 MIME-Version: 1.0 In-Reply-To: <20160316140458.44dcd97d.cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] Tweaks around virtio-blk start/stop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Kevin Wolf , Fam Zheng , qemu-block@nongnu.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, Christian Borntraeger , tubo@linux.vnet.ibm.com, Stefan Hajnoczi On 16/03/2016 14:04, Cornelia Huck wrote: > > No, it would not. ioeventfd=off,vhost=on would mean: "when vhost is > > off, use vCPU thread notification". > > *confused* > > Is ioeventfd=off supposed to mean "don't talk to the kernel, do > everything in qemu"? For KVM, it means do everything in the QEMU vCPU thread (using userspace vmexits). >> > When turning on vhost you'd still stop ioeventfd (i.e. stop processing >> > the virtqueue in QEMU's main iothread), but you don't need to do >> > anything to the event notifier. vhost will pick it up and work on the >> > virtqueue if necessary. Likewise for dataplane. > > So "disassociate the handler and switch over to the new one"? Yes, if we prohibit combinations which switch from vCPU thread notification to vhost or dataplane (such as ioeventfd=off,vhost=on). If we always use an eventfd, we always have a handler to switch to. > > > > If they aren't, it should be okay to remove the > > > > virtio_queue_host_notifier_read call in > > > > virtio_queue_set_host_notifier_fd_handler and > > > > virtio_queue_aio_set_host_notifier_handler. That's because a handler > > > > for the notifier will always be set _somewhere_. It could be the usual > > > > ioeventfd handler, the vhost handler or the dataplane handler, but one > > > > will be there. > > > > > > It should; but we probably need to do a final read when we stop the > > > ioeventfd. > > > > I was thinking of handing the final read directly to the next guy who > > polls the event notifier instead. So, when called from vhost or > > dataplane, virtio_pci_stop_ioeventfd would use > > assign=true/set_handler=false ("a new notifier is going to be set up by > > the caller"). > > OK, then we'd need to pass a new parameter for this. Yes, agreed. > > The host notifier API unfortunately is full of indirections. I'm not > > sure how many of them are actually necessary. > > Oh yes, it's very hard to follow, especially with not-very-well defined > parameters. And full of duplicate code. If copied code were moved to the virtio bus level, it would be easier to change too. Paolo