From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRgH-0006qi-EF for qemu-devel@nongnu.org; Thu, 19 Nov 2015 11:03:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzRgD-0004Ky-B4 for qemu-devel@nongnu.org; Thu, 19 Nov 2015 11:03:29 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:16399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzRgD-0004Kj-5O for qemu-devel@nongnu.org; Thu, 19 Nov 2015 11:03:25 -0500 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NY200I4FKLMSC60@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Thu, 19 Nov 2015 16:03:22 +0000 (GMT) From: Pavel Fedin References: <011b01d122af$c60f7ce0$522e76a0$@samsung.com> <20151119125348-mutt-send-email-mst@redhat.com> <014b01d122bf$ab73dc90$025b95b0$@samsung.com> <20151119135725-mutt-send-email-mst@redhat.com> <564DBB39.3010207@redhat.com> <014e01d122c4$54073d30$fc15b790$@samsung.com> <20151119135516.67948855.cornelia.huck@de.ibm.com> In-reply-to: <20151119135516.67948855.cornelia.huck@de.ibm.com> Date: Thu, 19 Nov 2015 19:03:20 +0300 Message-id: <01aa01d122e3$d04ddf60$70e99e20$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-language: ru Subject: Re: [Qemu-devel] [PATCH] virtio: Implement userspace forwarding for host notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Cornelia Huck' Cc: 'Paolo Bonzini' , "'Michael S. Tsirkin'" , qemu-devel@nongnu.org, 'Christian Borntraeger' Hello! > If I read this correctly, memory regions already keep track of > ioeventfds and this patch can simply trigger them manually if that had > not already been done? Yes, exactly, and this is the new idea. > Only that we don't have such a nice tracking structure that memory > regions already have. > > The intercept handler for diagnose 500 already ends up at the correct > device (its id is one of the parameters), so I'd need to check for an > existing notifier on the virtqueue and trigger that instead of calling > virtio_queue_notify directly? Yes, absolutely correct, but only if the notifier has actually been installed. Pure userspace virtio will not do it, AFAIK, if we don't have KVM_CAP_IOEVENTFD. Take a careful look at virtio-mmio.c, you'll see that host notifiers are actually installed from two places: 1. virtio_mmio_start_ioeventfd() 2. virtio_mmio_set_host_notifier() Userspace implementation of virtio uses (1) path, while vhost uses (2). Note also that (1) does not do anything at all if KVM does not support ioeventfds. So, (1) case breaks up into two: 1a. userspace virtio, notifications triggered by handling MMIO writes in userspace 1b. userspace virtio, notifications triggered by ioeventfds, which are bound to MMIO in kernel I don't know why we have (1b) at all, because i'm in doubt there would be any noticeable performance advantage. But, i believe, there was some reason to implement it. Both (1) and (2) end up in the same internal routine, and the only difference is 'bool set_handler', which is set to false for vhost. This is what i rely on, and this is what you should detect too. PCI backend is a little bit more complicated to read, but it works absolutely in the same way. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia