From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device Date: Wed, 16 Dec 2015 22:55:12 +0100 Message-ID: <5671DDC0.6040507@redhat.com> References: <1449166972-8894-1-git-send-email-yunhong.jiang@linux.intel.com> <5671A5DD.5060708@redhat.com> <1450293323.2674.37.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org To: Alex Williamson , Yunhong Jiang Return-path: In-Reply-To: <1450293323.2674.37.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 16/12/2015 20:15, Alex Williamson wrote: > The consumers would be, for instance, Intel PI + the threaded handler > added in this series. These run independently, the PI bypass simply > makes the interrupt disappear from the host when it catches it, but if > the vCPU isn't running in the right place at the time of the interrupt, > it gets delivered to the host, in which case the secondary consumer > implementing handle_irq() provides a lower latency injection than the > eventfd path. If PI isn't supported, only this latter consumer is > registered. I would implement the two in a single consumer, knowing that only one of the two parts would effectively run. But because of the possibility of multiple consumers implementing handle_irq(), I am not sure if this is feasible. > On the surface it seems like a reasonable solution, though having > multiple consumers implementing handle_irq() seems problematic. Do we > get multiple injections if we call them all? Indeed. > Should we have some way > to prioritize one handler versus another? Perhaps KVM should have a > single unified consumer that can provide that sort of logic, though we > still need the srcu code added here to protect against registration and > irq_handler() races. Thanks, I'm happy to see that we have the same doubts. :) Paolo