linux-kernel - Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1435175367.3700.316.camel@redhat.com>
Date:	Wed, 24 Jun 2015 13:49:27 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Eric Auger <eric.auger@...aro.org>
Cc:	Joerg Roedel <joro@...tes.org>, Avi Kivity <avi.kivity@...il.com>,
	"Wu, Feng" <feng.wu@...el.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"mtosatti@...hat.com" <mtosatti@...hat.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.  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/