On 14/07/16 16:35, Andre Przywara wrote:
> 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 n
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 c
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 b/arch/arm64/kvm/sys_regs.c
> in
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 Przywara
> Cc: Christoffer Dall
> Cc: Eric Auger
>
On 14/07/16 12:11, Andre Przywara wrote:
> 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'
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 devi
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 4
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.
>
> Anothe
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 implemen
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 b
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 vgic
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
>> routin
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
>
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 priori
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 a/virt/kvm/i
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 be
> read from guest memory upon enabling LPIs for
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
>> w
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 handl
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 t
19 matches
Mail list logo