On 11/07/16 18:47, Andre Przywara wrote:
> Hi,
>
> On 11/07/16 18:17, Marc Zyngier wrote:
>> On 05/07/16 12:23, Andre Przywara wrote:
>>> The connection between a device, an event ID, the LPI number and the
>>> allocated CPU is stored in in-memory tables in a GICv3, but their
>>> format is not spe
Hi,
On 11/07/16 18:17, Marc Zyngier wrote:
> On 05/07/16 12:23, Andre Przywara wrote:
>> The connection between a device, an event ID, the LPI number and the
>> allocated CPU is stored in in-memory tables in a GICv3, but their
>> format is not specified by the spec. Instead software uses a command
Hi,
On 11/07/16 17:50, Marc Zyngier wrote:
> On 05/07/16 12:23, 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 this
>> data in our struct vgic_irq. The initial pending state must be read
On 05/07/16 12:22, 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.
>
> This t
On 05/07/16 12:23, Andre Przywara wrote:
> The connection between a device, an event ID, the LPI number and the
> allocated 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 the ITS implemen
On 05/07/16 12:23, 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
On 05/07/16 12:23, 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 this
> data in our struct vgic_irq. The initial pending state must be read
> from guest memory upon enabling LPIs for this
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
> routing for arm too.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v4
Hi,
On 06/07/16 09:47, Eric Auger wrote:
> Up to now, only irqchip routing entries could be set. This patch
> adds the capability to insert MSI routing entries.
>
> For ARM64, let's also increase KVM_MAX_IRQ_ROUTES to 4096: this
> include SPI irqchip routes plus MSI routes. In the future this
> m
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
> when targeting multiple irqchips.
>
> Routing standard callbacks
Hi,
On 06/07/16 09:47, Eric Auger wrote:
> on ARM, a devid field is populated in kvm_msi struct in case the
> flag is set to KVM_MSI_VALID_DEVID. Let's propagate both flags and
> devid field in kvm_kernel_irq_routing_entry.
>
> Signed-off-by: Eric Auger
> Acked-by: Christoffer Dall
So apart fr
Hi,
On 06/07/16 09:47, Eric Auger wrote:
> Extend kvm_kernel_irq_routing_entry to transport the device id
> field, devid. A new flags field makes possible to indicate the
> devid is valid. Those additions are used for ARM GICv3 ITS MSI
> injection.
>
> Signed-off-by: Eric Auger
> Acked-by: Chris
Hi Eric,
On 06/07/16 09:47, Eric Auger wrote:
> On ARM, the MSI msg (address and data) comes along with
> out-of-band device ID information. The device ID encodes the
> device that writes the MSI msg. Let's convey the device id in
> kvm_irq_routing_msi and use KVM_MSI_VALID_DEVID flag value in
> k
On 05/07/16 12:23, Andre Przywara wrote:
> LPIs are dynamically created (mapped) at guest runtime and their
> actual number can be quite high, but is mostly assigned using a very
> sparse allocation scheme. So arrays are not an ideal data structure
> to hold the information.
> We use a spin-lock pr
On 11/07/16 10:00, Andre Przywara wrote:
> Hi,
>
> On 08/07/16 15:58, Marc Zyngier wrote:
>> On 05/07/16 12:23, 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,CRE
From: Richard Cochran
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
The VGIC callback is run after KVM's main callback since it reflects the
makefile order.
Signed-off-by: Anna-Maria Gleixner
Reviewed-by: Sebastian Andrzej Siewior
From: Richard Cochran
Install the callbacks via the state machine and let the core invoke
the callbacks on the already online CPUs.
Signed-off-by: Richard Cochran
Reviewed-by: Sebastian Andrzej Siewior
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Gleb Natapov
Cc: Paolo Bonzini
Cc: kvmarm@list
Hi,
On 08/07/16 15:58, Marc Zyngier wrote:
> On 05/07/16 12:23, 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 bu
On 08/07/16 16:40, Christoffer Dall wrote:
Hi Christoffer,
thanks very much for taking a look!
> On Tue, Jul 05, 2016 at 12:23:00PM +0100, Andre Przywara wrote:
>> In the GICv3 redistributor there are the PENDBASER and PROPBASER
>> registers which we did not emulate so far, as they only make sen
19 matches
Mail list logo
