Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754099AbbFOGmo (ORCPT ); Mon, 15 Jun 2015 02:42:44 -0400 Received: from mga14.intel.com ([192.55.52.115]:40245 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753857AbbFOGmf (ORCPT ); Mon, 15 Jun 2015 02:42:35 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,617,1427785200"; d="scan'208";a="746761248" From: "Wu, Feng" To: Alex Williamson , Avi Kivity CC: "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "pbonzini@redhat.com" , "mtosatti@redhat.com" , "eric.auger@linaro.org" , "Wu, Feng" Subject: RE: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding Thread-Topic: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding Thread-Index: AQHQpUKH3jSEQw7RikmlNDUvzTQMLp2tIc3Q Date: Mon, 15 Jun 2015 06:42:19 +0000 Message-ID: References: <1434019912-15423-1-git-send-email-feng.wu@intel.com> <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> In-Reply-To: <1434135815.4927.308.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t5F6gnwT026155 Content-Length: 4434 Lines: 89 > -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@redhat.com] > Sent: Saturday, June 13, 2015 3:04 AM > To: Avi Kivity > Cc: Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org; > pbonzini@redhat.com; mtosatti@redhat.com; eric.auger@linaro.org > Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding > > On Fri, 2015-06-12 at 21:48 +0300, Avi Kivity wrote: > > On 06/12/2015 06:41 PM, Alex Williamson wrote: > > > On Fri, 2015-06-12 at 00:23 +0000, Wu, Feng wrote: > > >>> -----Original Message----- > > >>> From: Avi Kivity [mailto:avi.kivity@gmail.com] > > >>> Sent: Friday, June 12, 2015 3:59 AM > > >>> To: Wu, Feng; kvm@vger.kernel.org; linux-kernel@vger.kernel.org > > >>> Cc: pbonzini@redhat.com; mtosatti@redhat.com; > > >>> alex.williamson@redhat.com; eric.auger@linaro.org > > >>> Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding > > >>> > > >>> On 06/11/2015 01:51 PM, Feng Wu wrote: > > >>>> From: Eric Auger > > >>>> > > >>>> This patch adds and documents a new KVM_DEV_VFIO_DEVICE group > > >>>> and 2 device attributes: KVM_DEV_VFIO_DEVICE_FORWARD_IRQ, > > >>>> KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ. The purpose is to be able > > >>>> to set a VFIO device IRQ as forwarded or not forwarded. > > >>>> the command takes as argument a handle to a new struct named > > >>>> kvm_vfio_dev_irq. > > >>> Is there no way to do this automatically? After all, vfio knows that a > > >>> device interrupt is forwarded to some eventfd, and kvm knows that some > > >>> eventfd is forwarded to a guest interrupt. If they compare notes > > >>> through a central registry, they can figure out that the interrupt needs > > >>> to be forwarded. > > >> Oh, just like Eric mentioned in his reply, this description is out of context of > > >> this series, I will remove them in the next version. > > > > > > I suspect Avi's question was more general. While forward/unforward is > > > out of context for this series, it's very similar in nature to > > > enabling/disabling posted interrupts. So I think the question remains > > > whether we really need userspace to participate in creating this > > > shortcut or if kvm and vfio can some how orchestrate figuring it out > > > automatically. > > > > > > Personally I don't know how we could do it automatically. We've always > > > relied on userspace to independently setup vfio and kvm such that > > > neither have any idea that the other is there and update each side > > > independently when anything changes. So it seems consistent to continue > > > that here. It doesn't seem like there's much to gain performance-wise > > > either, updates should be a relatively rare event I'd expect. > > > > > > There's really no metadata associated with an eventfd, so "comparing > > > notes" automatically might imply some central registration entity. That > > > immediately sounds like a much more complex solution, but maybe Avi has > > > some ideas to manage it. Thanks, > > > > > > > The idea is to have a central registry maintained by a posted interrupts > > manager. Both vfio and kvm pass the filp (along with extra information) > > to the posted interrupts manager, which, when it detects a filp match, > > tells each of them what to do. > > > > The advantages are: > > - old userspace gains the optimization without change > > - a userspace API is more expensive to maintain than internal kernel > > interfaces (CVEs, documentation, maintaining backwards compatibility) > > - if you can do it without a new interface, this indicates that all the > > information in the new interface is redundant. That means you have to > > check it for consistency with the existing information, so it's extra > > work (likely, it's exactly what the posted interrupt manager would be > > doing anyway). > > Yep, those all sound like good things and I believe that's similar in > design to the way we had originally discussed this interaction at > LPC/KVM Forum several years ago. I'd be in favor of that approach. > Thanks, This seems a little complex compared to the current solution, since I am not quite familiar with VFIO, Alex, can you help on this if we need to do this that way, especially for the VFIO part? Thanks, Feng > > Alex ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?