From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49894) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqfY8-0004oF-JU for qemu-devel@nongnu.org; Fri, 08 May 2015 06:30:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YqfY5-0004Jc-45 for qemu-devel@nongnu.org; Fri, 08 May 2015 06:30:32 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:63516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YqfY4-0004JU-IT for qemu-devel@nongnu.org; Fri, 08 May 2015 06:30:28 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NO100HS516K9L80@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Fri, 08 May 2015 11:30:20 +0100 (BST) From: Pavel Fedin References: <016001d088b3$8da9bfa0$a8fd3ee0$@samsung.com> <20150507153942.29afef5f.cornelia.huck@de.ibm.com> <00aa01d0895a$81d423d0$857c6b70$@samsung.com> <20150508122029.30e0311d.cornelia.huck@de.ibm.com> In-reply-to: <20150508122029.30e0311d.cornelia.huck@de.ibm.com> Date: Fri, 08 May 2015 13:30:18 +0300 Message-id: <007801d08979$fb8267e0$f28737a0$@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 v2 2/3] virtio-mmio: introduce set_guest_notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Cornelia Huck' Cc: qemu-devel@nongnu.org Hello! > Yes, I think it makes sense to just pick the low-hanging fruit for > virtio-mmio and wait for pci. Does this mean that my series can be accepted as it is? Since PCI is potentially better solution, MMIO is a low priority in my project, and i have lots of other tasks. This means i unfortunately don't have time for further refactor. If you ACK, i will resend the series once again as v3, i set up git send-email and it should be working now. I just wanted to share this piece because it's already done, and i would not like it to go to oblivion again. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia > -----Original Message----- > From: qemu-devel-bounces+p.fedin=samsung.com@nongnu.org [mailto:qemu-devel- > bounces+p.fedin=samsung.com@nongnu.org] On Behalf Of Cornelia Huck > Sent: Friday, May 08, 2015 1:20 PM > To: Pavel Fedin > Cc: qemu-devel@nongnu.org > Subject: Re: [Qemu-devel] [PATCH v2 2/3] virtio-mmio: introduce set_guest_notifiers > > On Fri, 08 May 2015 09:45:00 +0300 > Pavel Fedin wrote: > > > Hello! > > > > > Hm, weren't there some patches for irqfd on arm? > > > > Yes, there were. However, they had a design problem by breaking backwards compatibility > > with unmodified virtio. Their idea was to set up one more shared memory area between > > virtio and vhost-net and use it to pass ISR value, which helps to distinguish, which event > > took place (queue update or config change). So, this idea was rejected. > > http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg03056.html > > > > I thought about it, and technically, i think, this can be done in better way. Actually, > > as far as i understood, all we need is mechanism for distinguishing between these two > > events. On PCI we do this by using multiple IRQs via MSI-X, and one IRQ signals exactly > > one type of event. MSI-X code also has "two IRQs" mode as a failsafe, where one IRQ > > signals config change and another IRQ signals queues update (and all queues are polled in > > turn). I think a similar thing could be done for virtio-mmio. It could allocate two IRQs > > instead of one and describe both of them in the device tree. Guest side, upon seeing that, > > could make use of those two IRQs and acknowledge to the host side that "yes, i am new > > version and use new mode". > > But, sorry, i will unlikely implement this, because we already have PCI with MSI-X (i > > hope this is going to be published soon), so my project can use PCI emulation. So > > implementing irqfds for virtio-mmio is a bit out of my scope. > > Thanks for the explanation. >