On Fri, 08 May 2015 09:45:00 +0300 Pavel Fedin <p.fe...@samsung.com> 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. Yes, I think it makes sense to just pick the low-hanging fruit for virtio-mmio and wait for pci.
