[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 2/3] virtio-mmio: introduce set_guest_notifie
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH v2 2/3] virtio-mmio: introduce set_guest_notifiers |
Date: |
Fri, 8 May 2015 12:20:29 +0200 |
On Fri, 08 May 2015 09:45:00 +0300
Pavel Fedin <address@hidden> 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.