Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752549AbbFYB5k (ORCPT ); Wed, 24 Jun 2015 21:57:40 -0400 Received: from mga01.intel.com ([192.55.52.88]:28808 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751123AbbFYB5b (ORCPT ); Wed, 24 Jun 2015 21:57:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,674,1427785200"; d="scan'208";a="749962353" From: "Wu, Feng" To: Alex Williamson , Eric Auger CC: Joerg Roedel , Avi Kivity , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "pbonzini@redhat.com" , "mtosatti@redhat.com" , "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: AQHQrrbnQxwYKPMHSEuQZ77CYK09WZ28dqnA Date: Thu, 25 Jun 2015 01:57:25 +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> <557EFA7F.9010209@linaro.org> <20150624155005.GC18569@8bytes.org> <558AD9E6.1030902@linaro.org> <1435175367.3700.316.camel@redhat.com> In-Reply-To: <1435175367.3700.316.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 t5P1vhwE020251 Content-Length: 3145 Lines: 67 > -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@redhat.com] > Sent: Thursday, June 25, 2015 3:49 AM > To: Eric Auger > Cc: Joerg Roedel; Avi Kivity; Wu, Feng; 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 Wed, 2015-06-24 at 18:25 +0200, Eric Auger wrote: > > Hi Joerg, > > > > On 06/24/2015 05:50 PM, Joerg Roedel wrote: > > > On Mon, Jun 15, 2015 at 06:17:03PM +0200, Eric Auger wrote: > > >> I guess this discussion also is relevant wrt "[RFC v6 00/16] KVM-VFIO > > >> IRQ forward control" series? Or is that "central registry maintained by > > >> a posted interrupts manager" something more specific to x86? > > > > > > From what I understood so far, the feature you implemented for ARM is a > > > bit different from the ones that get introduced to x86. > > > > > > Can you please share some details on how the ARM version works? I am > > > interested in how the GICv2 is configured for IRQ forwarding. The > > > question is whether the forwarding information needs to be updated from > > > KVM and what information about the IRQ KVM needs for this. > > > > The principle is that when you inject a virtual IRQ to a guest, you > > program a register in the GIC, known as a list register. There you put > > both the virtual IRQ you want to inject but also the physical IRQ it is > > linked with (HWbit mode set = forwarding set). When the guest completes > > the virtual IRQ the GIC HW automatically deactivates the physical IRQ > > found in the list register. In that mode the physical IRQ deactivation > > is under the ownership of the guest (actually automatically done by the HW). > > > > If HWbit mode is *not* set (forwarding not set), you do not specify the > > HW IRQ in the list register. The host deactivates the physical IRQ & > > masks it before triggering the virtual IRQ. Only the virtual IRQ ID is > > programmed in the list register. When the guest completes the virtual > > IRQ, a physical maintenance IRQ is triggered. The hyp mode is entered > > and eventually the host unmasks the IRQ. > > > > Some illustrations can be found in > > http://www.linux-kvm.org/images/a/a8/01x04-ARMdevice.pdf > > > I think an important aspect for our design is that in the case of Posted > Interrupts, they're only used for edge triggered interrupts so VFIO is > only an information provider for KVM to configure it. Exactly! For PI, KVM only needs some information from VFIO when the guests set the irq affinity. Thanks, Feng VFIO will > hopefully just see fewer interrupts as they magically appear directly in > the guest. IRQ Forwarding however affects the de-assertion of level > triggered interrupts. VFIO needs to switch to something more like an > edge handler when IRQ Forwarding is enabled. So in that model, VFIO > needs to provide information as well as consume it to change behavior. > Thanks, > > Alex ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?