From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753606AbbFXTtd (ORCPT ); Wed, 24 Jun 2015 15:49:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38724 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752412AbbFXTt3 (ORCPT ); Wed, 24 Jun 2015 15:49:29 -0400 Message-ID: <1435175367.3700.316.camel@redhat.com> Subject: Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding From: Alex Williamson 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" Date: Wed, 24 Jun 2015 13:49:27 -0600 In-Reply-To: <558AD9E6.1030902@linaro.org> 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> 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 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. 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