Re: [PATCH v9 15/17] KVM: arm64: implement ITS command queue command handlers

2016-07-14 Thread Andre Przywara
Hi Marc, On 14/07/16 11:38, Marc Zyngier wrote: > On 13/07/16 02:59, Andre Przywara wrote: >> The connection between a device, an event ID, the LPI number and the >> associated CPU is stored in in-memory tables in a GICv3, but their >> format is not specified by the spec. Instead software uses a

Re: [patch] arm64: KVM: clean up a condition

2016-07-14 Thread Marc Zyngier
On 14/07/16 11:19, Dan Carpenter wrote: > My static checker complains that this condition looks like it should be > == instead of =. This isn't a fast path, so we don't need to be fancy. > > Signed-off-by: Dan Carpenter > > diff --git a/arch/arm64/kvm/sys_regs.c

Re: [patch V2 60/67] KVM/arm/arm64/vgic-new: Convert to hotplug state machine

2016-07-14 Thread Marc Zyngier
On 13/07/16 18:17, Anna-Maria Gleixner wrote: > From: Anna-Maria Gleixner > > Install the callbacks via the state machine and let the core invoke > the callbacks on the already online CPUs. > > Signed-off-by: Anna-Maria Gleixner > Cc: Andre

Re: [PATCH v9 10/17] KVM: arm64: introduce new KVM ITS device

2016-07-14 Thread Andre Przywara
Hi, On 14/07/16 09:36, Marc Zyngier wrote: > On 13/07/16 02:59, Andre Przywara wrote: >> Introduce a new KVM device that represents an ARM Interrupt Translation >> Service (ITS) controller. Since there can be multiple of this per guest, >> we can't piggy back on the existing GICv3 distributor

Re: [PATCH v9 00/17] KVM: arm64: GICv3 ITS emulation

2016-07-14 Thread Paolo Bonzini
On 14/07/2016 12:52, Marc Zyngier wrote: > I'm done with that round. Couple of annoying bugs, and still a bunch of > loose ends to be tied. Timing wise, this is getting pretty tight for > 4.8, so unless you address the comments very quickly, it will be a miss > again. > > My plan is to cut the

Re: [PATCH v9 00/17] KVM: arm64: GICv3 ITS emulation

2016-07-14 Thread Marc Zyngier
On 13/07/16 02:58, Andre Przywara wrote: > Hi, > > this series allows those KVM guests that use an emulated GICv3 to use LPIs > as well, though in the moment this is limited to emulated PCI devices. > This is based on kvmarm/queue, which now only features the new VGIC > implementation. > >

Re: [PATCH v9 15/17] KVM: arm64: implement ITS command queue command handlers

2016-07-14 Thread Marc Zyngier
On 13/07/16 02:59, Andre Przywara wrote: > The connection between a device, an event ID, the LPI number and the > associated CPU is stored in in-memory tables in a GICv3, but their > format is not specified by the spec. Instead software uses a command > queue in a ring buffer to let an ITS

Re: [PATCH v9 13/17] KVM: arm64: read initial LPI pending table

2016-07-14 Thread Andre Przywara
Hi, On 14/07/16 10:34, Marc Zyngier wrote: > On 13/07/16 02:59, Andre Przywara wrote: >> The LPI pending status for a GICv3 redistributor is held in a table >> in (guest) memory. To achieve reasonable performance, we cache the >> pending bit in our struct vgic_irq. The initial pending state must

Re: [PATCH v9 14/17] KVM: arm64: allow updates of LPI configuration table

2016-07-14 Thread Marc Zyngier
On 14/07/16 11:00, Andre Przywara wrote: > Hi, > > On 14/07/16 10:46, Marc Zyngier wrote: >> On 13/07/16 02:59, Andre Przywara wrote: >>> The (system-wide) LPI configuration table is held in a table in >>> (guest) memory. To achieve reasonable performance, we cache this data >>> in our struct

Re: [RFC v6 6/6] KVM: arm: enable KVM_SIGNAL_MSI and MSI routing

2016-07-14 Thread Auger Eric
Hi Andre, On 11/07/2016 18:26, Andre Przywara wrote: > Hi, > > On 06/07/16 09:47, Eric Auger wrote: >> If the ITS modality is not available, let's simply support MSI >> injection by transforming the MSI.data into an SPI ID. >> >> This becomes possible to use KVM_SIGNAL_MSI ioctl and MSI >>

Re: [PATCH v9 14/17] KVM: arm64: allow updates of LPI configuration table

2016-07-14 Thread Andre Przywara
Hi, On 14/07/16 10:46, Marc Zyngier wrote: > On 13/07/16 02:59, Andre Przywara wrote: >> The (system-wide) LPI configuration table is held in a table in >> (guest) memory. To achieve reasonable performance, we cache this data >> in our struct vgic_irq. If the guest updates the configuration data

Re: [PATCH v9 14/17] KVM: arm64: allow updates of LPI configuration table

2016-07-14 Thread Marc Zyngier
On 13/07/16 02:59, Andre Przywara wrote: > The (system-wide) LPI configuration table is held in a table in > (guest) memory. To achieve reasonable performance, we cache this data > in our struct vgic_irq. If the guest updates the configuration data > (which consists of the enable bit and the

Re: [RFC v6 4/6] KVM: arm/arm64: enable irqchip routing

2016-07-14 Thread Auger Eric
Hi Drew, Radim, On 08/07/2016 22:55, Radim Krčmář wrote: > 2016-07-08 10:52+0200, Andrew Jones: >> On Fri, Jul 08, 2016 at 10:16:53AM +0200, Auger Eric wrote: >>> On 07/07/2016 19:20, Andrew Jones wrote: On Wed, Jul 06, 2016 at 10:47:53AM +0200, Eric Auger wrote: > diff --git

Re: [RFC v6 4/6] KVM: arm/arm64: enable irqchip routing

2016-07-14 Thread Auger Eric
Hi Andre, On 11/07/2016 18:25, Andre Przywara wrote: > Hi Eric, > > On 06/07/16 09:47, Eric Auger wrote: >> This patch adds compilation and link against irqchip. >> >> Main motivation behind using irqchip code is to enable MSI >> routing code. In the future irqchip routing may also be useful >>

Re: [PATCH v9 11/17] KVM: arm64: implement basic ITS register handlers

2016-07-14 Thread Marc Zyngier
On 13/07/16 02:59, Andre Przywara wrote: > Add emulation for some basic MMIO registers used in the ITS emulation. > This includes: > - GITS_{CTLR,TYPER,IIDR} > - ID registers > - GITS_{CBASER,CREADR,CWRITER} > (which implement the ITS command buffer handling) > - GITS_BASER > > Most of the

Re: [PATCH v9 10/17] KVM: arm64: introduce new KVM ITS device

2016-07-14 Thread Marc Zyngier
On 13/07/16 02:59, Andre Przywara wrote: > Introduce a new KVM device that represents an ARM Interrupt Translation > Service (ITS) controller. Since there can be multiple of this per guest, > we can't piggy back on the existing GICv3 distributor device, but create > a new type of KVM device. > On