Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967045AbbLPVzR (ORCPT ); Wed, 16 Dec 2015 16:55:17 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37494 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966666AbbLPVzP (ORCPT ); Wed, 16 Dec 2015 16:55:15 -0500 Subject: Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device To: Alex Williamson , Yunhong Jiang References: <1449166972-8894-1-git-send-email-yunhong.jiang@linux.intel.com> <5671A5DD.5060708@redhat.com> <1450293323.2674.37.camel@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org From: Paolo Bonzini Message-ID: <5671DDC0.6040507@redhat.com> Date: Wed, 16 Dec 2015 22:55:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1450293323.2674.37.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1566 Lines: 37 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/