From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752225AbcAFHpj (ORCPT ); Wed, 6 Jan 2016 02:45:39 -0500 Received: from mga11.intel.com ([192.55.52.93]:57183 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751582AbcAFHpg (ORCPT ); Wed, 6 Jan 2016 02:45:36 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,528,1444719600"; d="scan'208";a="875488975" Date: Tue, 5 Jan 2016 23:42:07 -0800 From: Yunhong Jiang To: Paolo Bonzini Cc: Alex Williamson , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device Message-ID: <20160106074207.GB15116@jnakajim-build> References: <1449166972-8894-1-git-send-email-yunhong.jiang@linux.intel.com> <5671A5DD.5060708@redhat.com> <1450293323.2674.37.camel@redhat.com> <5671DDC0.6040507@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5671DDC0.6040507@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 16, 2015 at 10:55:12PM +0100, Paolo Bonzini wrote: > > > 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. So is it possible that we limit only one consumer with handle_irq(), as my previous response to Alex? We can extend it in future if we do need support multiple consumder implementing handle_irq()? Thanks --jyh > > > 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/