Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752215AbbFYPMD (ORCPT ); Thu, 25 Jun 2015 11:12:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46406 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751171AbbFYPLy (ORCPT ); Thu, 25 Jun 2015 11:11:54 -0400 Message-ID: <1435245112.3700.365.camel@redhat.com> Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding From: Alex Williamson To: "Wu, Feng" Cc: Joerg Roedel , Eric Auger , Avi Kivity , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "pbonzini@redhat.com" , "mtosatti@redhat.com" Date: Thu, 25 Jun 2015 09:11:52 -0600 In-Reply-To: References: <1434019912-15423-9-git-send-email-feng.wu@intel.com> <5579E884.3040500@gmail.com> <1434123695.4927.304.camel@redhat.com> <557B2994.1070900@gmail.com> <1434135815.4927.308.camel@redhat.com> <557EFA7F.9010209@linaro.org> <1434386702.4927.391.camel@redhat.com> <1434657848.3700.83.camel@redhat.com> <20150624154616.GB18569@8bytes.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2941 Lines: 63 On Thu, 2015-06-25 at 09:37 +0000, Wu, Feng wrote: > > > -----Original Message----- > > From: Joerg Roedel [mailto:joro@8bytes.org] > > Sent: Wednesday, June 24, 2015 11:46 PM > > To: Alex Williamson > > Cc: Wu, Feng; Eric Auger; Avi Kivity; kvm@vger.kernel.org; > > linux-kernel@vger.kernel.org; pbonzini@redhat.com; mtosatti@redhat.com > > Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding > > > > On Thu, Jun 18, 2015 at 02:04:08PM -0600, Alex Williamson wrote: > > > There are plenty of details to be filled in, > > > > I also need to fill plenty of details in my head first, so here are some > > suggestions based on my current understanding. Please don't hesitate to > > correct me if where I got something wrong. > > > > So first I totally agree that the handling of PI/non-PI configurations > > should be transparent to user-space. > > After thinking about this a bit more, I recall that why I used user-space > to trigger the IRTE update for posted-interrupts, here is the reason: > > Let's take MSI for an example: > When guest updates the MSI configuration, here is the code path in > QEMU and KVM: > > vfio_update_msi() --> vfio_update_kvm_msi_virq() --> > kvm_irqchip_update_msi_route() --> kvm_update_routing_entry() --> > kvm_irqchip_commit_routes() --> kvm_irqchip_commit_routes() --> > KVM_SET_GSI_ROUTING --> kvm_set_irq_routing() > > It will finally go to kvm_set_irq_routing() in KVM, there are two problem: > 1. It use RCU in this function, it is hard to find which entry in the irq routing > table is being updated. > 2. Even we find the updated entry, it is hard to find the associated assigned > device with this irq routing entry. > > So I used a VFIO API to notify KVM the updated MSI/MSIx configuration and > the associated assigned devices. I think we need to find a way to address > the above two issues before going forward. Alex, what is your opinion? So the trouble is that QEMU vfio updates a single MSI vector, but that just updates a single entry within a whole table of routes, then the whole table is pushed to KVM. But in kvm_set_irq_routing() we have access to both the new and the old tables, so we do have the ability to detect the change. We can therefore detect which GSI changed and cross-reference that to KVMs irqfds. If we have an irqfd that matches the GSI then we have all the information we need, right? We can use the eventfd_ctx of the irqfd to call into the IRQ bypass manager if we need to. If it's an irqfd that's already enabled for bypass then we may already have the data we need to tweak the PI config. Yes, I agree it's more difficult, but it doesn't appear to be impossible, right? Thanks, Alex -- 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/