Re: [PATCH v5 5/5] KVM: eventfd: add irq bypass consumer management

2015-08-12 Thread Alex Williamson
On Mon, 2015-08-10 at 15:31 +0200, Eric Auger wrote: > This patch adds the registration/unregistration of an > irq_bypass_consumer on irqfd assignment/deassignment. > > Signed-off-by: Eric Auger > Signed-off-by: Feng Wu > > --- > > v4 -> v5: > - due to removal of static inline stubs, add > #

Re: [PATCH v3 06/10] VFIO: platform: add irq bypass producer management

2015-08-12 Thread Alex Williamson
On Mon, 2015-08-10 at 15:21 +0200, Eric Auger wrote: > This patch populates the IRQ bypass callacks: > - stop/start producer simply consist in disabling/enabling the host irq > - add/del consumer: basically set the automasked flag to false/true > > Signed-off-by: Eric Auger > > --- > v2 -> v3: >

Re: [PATCH v3 04/10] VFIO: platform: add vfio_platform_set_automasked

2015-08-12 Thread Alex Williamson
On Mon, 2015-08-10 at 15:20 +0200, Eric Auger wrote: > This function makes possible to change the automasked mode. > > Signed-off-by: Eric Auger > > --- > > v1 -> v2: > - set forwarded flag > --- > drivers/vfio/platform/vfio_platform_irq.c | 19 +++ > 1 file changed, 19 inserti

Re: [PATCH v3 05/10] VFIO: platform: add vfio_platform_is_active

2015-08-12 Thread Alex Williamson
On Mon, 2015-08-10 at 15:20 +0200, Eric Auger wrote: > This function returns whether the IRQ is active at irqchip level or > VFIO masked. If either is true, it is considered the IRQ is active. > Currently there is no way to differentiate userspace masked IRQ from > automasked IRQ. There might be fa

Re: [PATCH v3 03/10] VFIO: platform: single handler using function pointer

2015-08-12 Thread Alex Williamson
On Mon, 2015-08-10 at 15:20 +0200, Eric Auger wrote: > A single handler now is registered whatever the use case: automasked > or not. A function pointer is set according to the wished behavior > and the handler calls this function. > > The irq lock is taken/released in the root handler. eventfd_si

Re: [PATCH v3 01/10] VFIO: platform: registration of a dummy IRQ bypass producer

2015-08-12 Thread Alex Williamson
On Mon, 2015-08-10 at 15:20 +0200, Eric Auger wrote: > Register a dummy producer with void callbacks > > Signed-off-by: Eric Auger > > --- > > v2 -> v3: > - rename vfio_platform_irq_bypass_resume into *_start > --- > drivers/vfio/platform/vfio_platform_irq.c | 32 > +++

Re: [PATCH 2/6] irqchip: GIC: Convert to EOImode == 1

2015-08-12 Thread Catalin Marinas
On Wed, Aug 12, 2015 at 02:31:47PM +0100, Marc Zyngier wrote: > On 11/08/15 10:15, Eric Auger wrote: > > On 07/09/2015 03:19 PM, Marc Zyngier wrote: > >> static int gic_irq_set_irqchip_state(struct irq_data *d, > >> @@ -272,11 +278,15 @@ static void __exception_irq_entry > >> gic_handle_irq(struc

Re: KVM Live migration with GICv3

2015-08-12 Thread Marc Zyngier
On 11/08/15 06:25, Vijay Kilari wrote: > Hi, > >I have prototyped Live migration with GICv3. > For this I have made following changes > > 1) Save and Restore of GICv3 registers in QEMU. > - For GICv2, QEMU is saving/restoring GICD, GICC registers. For GICv3, > we have to save/restor

Re: KVM Live migration with GICv3

2015-08-12 Thread Peter Maydell
On 12 August 2015 at 17:17, Marc Zyngier wrote: > If you plan to do anything for GICv3, you should only deal with with the > system register version of the CPU interface. Also, please make sure that you think about (and in terms of) the underlying state inside the GIC, which is closely related to

Re: KVM Live migration with GICv3

2015-08-12 Thread Marc Zyngier
On 11/08/15 16:24, Pavel Fedin wrote: > Hello! > >> I mean CPU interface registers GICC* defined for vgicv2 under >> "vgic_cpu_ranges[]" in >> virt/kvm/arm/vgic-v2-emul.c needs to be saved and restored for vgicv3 as >> well. >> So to access vgic_cpu_ranges[] for vgicv3, we need to register devi

Re: [PATCH 5/6] irqchip: GICv3: Don't deactivate interrupts forwarded to a guest

2015-08-12 Thread Eric Auger
On 08/12/2015 05:40 PM, Marc Zyngier wrote: > On 12/08/15 16:09, Eric Auger wrote: >> On 08/12/2015 04:20 PM, Marc Zyngier wrote: >>> On 11/08/15 11:03, Eric Auger wrote: On 07/09/2015 03:19 PM, Marc Zyngier wrote: > Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to >

Re: [PATCH 5/6] irqchip: GICv3: Don't deactivate interrupts forwarded to a guest

2015-08-12 Thread Marc Zyngier
On 12/08/15 16:09, Eric Auger wrote: > On 08/12/2015 04:20 PM, Marc Zyngier wrote: >> On 11/08/15 11:03, Eric Auger wrote: >>> On 07/09/2015 03:19 PM, Marc Zyngier wrote: Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU") added just what we

Re: [PATCH 5/6] irqchip: GICv3: Don't deactivate interrupts forwarded to a guest

2015-08-12 Thread Eric Auger
On 08/12/2015 04:20 PM, Marc Zyngier wrote: > On 11/08/15 11:03, Eric Auger wrote: >> On 07/09/2015 03:19 PM, Marc Zyngier wrote: >>> Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to >>> target an interrupt to a VCPU") added just what we needed at the >>> lowest level to allow an

Re: [PATCH 3/6] irqchip: GICv3: Skip LPI deactivation

2015-08-12 Thread Eric Auger
On 08/12/2015 03:34 PM, Marc Zyngier wrote: > On 11/08/15 10:42, Eric Auger wrote: >> On 07/09/2015 03:19 PM, Marc Zyngier wrote: >>> Contrary to other GICv3 interrupts, LPIs do not have an active state >>> by virtue of being edge-triggered only (they only have a pending state). >>> >>> Given this,

Re: [PATCH 0/6] irqchip: GICv2/v3: Add support for irq_vcpu_affinity

2015-08-12 Thread Marc Zyngier
On 11/08/15 11:06, Eric Auger wrote: > Hi Marc, > > The series works fine with KVM platform device passthrough use case > (Calxeda Midway, GICv2, SPI assignment with VFIO). My integration branch > can be found at > https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.2-rc6-irq

Re: [PATCH 5/6] irqchip: GICv3: Don't deactivate interrupts forwarded to a guest

2015-08-12 Thread Marc Zyngier
On 11/08/15 11:03, Eric Auger wrote: > On 07/09/2015 03:19 PM, Marc Zyngier wrote: >> Commit 0a4377de3056 ("genirq: Introduce irq_set_vcpu_affinity() to >> target an interrupt to a VCPU") added just what we needed at the >> lowest level to allow an interrupt to be deactivated by a guest. >> >> When

Re: [PATCH 4/6] irqchip: GIC: Use chip_data instead of handler_data for cascaded interrupts

2015-08-12 Thread Marc Zyngier
On 11/08/15 10:45, Eric Auger wrote: > Hi Marc, > On 07/09/2015 03:19 PM, Marc Zyngier wrote: >> When used as a primary interrupt controller, the GIC driver uses >> irq_data->chip_data to extract controller-specific information. >> >> When used as a secondary interrupt controller, it uses handler_d

Re: [PATCH 3/6] irqchip: GICv3: Skip LPI deactivation

2015-08-12 Thread Marc Zyngier
On 11/08/15 10:42, Eric Auger wrote: > On 07/09/2015 03:19 PM, Marc Zyngier wrote: >> Contrary to other GICv3 interrupts, LPIs do not have an active state >> by virtue of being edge-triggered only (they only have a pending state). >> >> Given this, there is no point trying to deactivate them, and w

Re: [PATCH 2/6] irqchip: GIC: Convert to EOImode == 1

2015-08-12 Thread Marc Zyngier
Hi Eric, On 11/08/15 10:15, Eric Auger wrote: > Hi Marc, > On 07/09/2015 03:19 PM, Marc Zyngier wrote: >> So far, GICv2 has been used in with EOImode == 0. The effect of this >> mode is to perform the priority drop and the deactivation of the >> interrupt at the same time. >> >> While this works p

Re: [PATCH v2 05/15] KVM: arm/arm64: make GIC frame address initialization model specific

2015-08-12 Thread Eric Auger
On 07/10/2015 04:21 PM, Andre Przywara wrote: > Currently we initialize all the possible GIC frame addresses in one > function, without looking at the specific GIC model we instantiate > for the guest. > As this gets confusing when adding another VGIC model later, lets > move these initializations

Re: [PATCH 1/6] irqchip: GICv3: Convert to EOImode == 1

2015-08-12 Thread Marc Zyngier
On 11/08/15 10:14, Eric Auger wrote: > Hi Marc, > On 07/09/2015 03:19 PM, Marc Zyngier wrote: >> So far, GICv3 has been used in with EOImode == 0. The effect of this >> mode is to perform the priority drop and the deactivation of the >> interrupt at the same time. >> >> While this works perfectly f

Re: [PATCH v2 04/15] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities

2015-08-12 Thread Eric Auger
Reviewed-by: Eric Auger Best Regards Eric On 07/10/2015 04:21 PM, Andre Przywara wrote: > KVM capabilities can be a per-VM property, though ARM/ARM64 currently > does not pass on the VM pointer to the architecture specific > capability handlers. > Add a "struct kvm*" parameter to those function

Re: [PATCH v4 06/11] KVM: arm/arm64: vgic: Allow dynamic mapping of physical/virtual interrupts

2015-08-12 Thread Christoffer Dall
On Wed, Aug 12, 2015 at 10:56:38AM +0100, Marc Zyngier wrote: > On Tue, 11 Aug 2015 08:42:37 +0100 > Christoffer Dall wrote: > > > On Fri, Aug 07, 2015 at 04:45:42PM +0100, Marc Zyngier wrote: > > > In order to be able to feed physical interrupts to a guest, we need > > > to be able to establish

Re: [PATCH v4 06/11] KVM: arm/arm64: vgic: Allow dynamic mapping of physical/virtual interrupts

2015-08-12 Thread Marc Zyngier
On Tue, 11 Aug 2015 08:42:37 +0100 Christoffer Dall wrote: > On Fri, Aug 07, 2015 at 04:45:42PM +0100, Marc Zyngier wrote: > > In order to be able to feed physical interrupts to a guest, we need > > to be able to establish the virtual-physical mapping between the two > > worlds. > > > > The mapp

Re: [PATCH v2 01/15] KVM: arm/arm64: VGIC: don't track used LRs in the distributor

2015-08-12 Thread Eric Auger
Hi Andre, On 07/10/2015 04:21 PM, Andre Przywara wrote: > Currently we track which IRQ has been mapped to which VGIC list > register and also have to synchronize both. We used to do this > to hold some extra state (for instance the active bit). > It turns out that this extra state in the LRs is no