[PATCH v9 12/17] KVM: arm64: connect LPIs to the VGIC emulation

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 protected linked list to hold all mapped LPIs,

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

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 priority value), it issues an INV or INVALL command to

[PATCH v9 16/17] KVM: arm64: implement MSI injection in ITS emulation

When userland wants to inject an MSI into the guest, it uses the KVM_SIGNAL_MSI ioctl, which carries the doorbell address along with the payload and the device ID. With the help of the KVM IO bus framework we learn the corresponding ITS from the doorbell address. We then use our wrapper functions

[PATCH v9 08/17] KVM: arm64: handle ITS related GICv3 redistributor registers

In the GICv3 redistributor there are the PENDBASER and PROPBASER registers which we did not emulate so far, as they only make sense when having an ITS. In preparation for that emulate those MMIO accesses by storing the 64-bit data written into it into a variable which we later read in the ITS

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

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 this redistributor. As we can't access the

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

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 handlers are pretty straight forward, only the CWRITER handler

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

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 implementation use its own format. Implement handlers

[PATCH v9 03/17] KVM: extend struct kvm_msi to hold a 32-bit device ID

The ARM GICv3 ITS MSI controller requires a device ID to be able to assign the proper interrupt vector. On real hardware, this ID is sampled from the bus. To be able to emulate an ITS controller, extend the KVM MSI interface to let userspace provide such a device ID. For PCI devices, the device ID

[PATCH v9 02/17] KVM: arm/arm64: check return value for kvm_register_vgic_device

kvm_register_device_ops() can return an error, so lets check its return value and propagate this up the call chain. Signed-off-by: Andre Przywara --- virt/kvm/arm/vgic/vgic-kvm-device.c | 15 +-- virt/kvm/arm/vgic/vgic-v2.c | 11 ---

[PATCH v9 07/17] irqchip: refactor and add GICv3 definitions

arm-gic-v3.h contains bit and register definitions for the GICv3 and ITS, at least for the bits the we currently care about. The ITS emulation needs more definitions, so add them and refactor the memory attribute #defines to be more universally usable. To avoid changing all users, we still provide

[PATCH v9 04/17] KVM: arm/arm64: extend arch CAP checks to allow per-VM capabilities

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 to later allow proper per-VM capability reporting. Signed-off-by: Andre Przywara

[PATCH v9 09/17] KVM: arm64: introduce ITS emulation file with MMIO framework

The ARM GICv3 ITS emulation code goes into a separate file, but needs to be connected to the GICv3 emulation, of which it is an option. The ITS MMIO handlers require the respective ITS pointer to be passed in, so we amend the existing VGIC MMIO framework to let it cope with that. Also we introduce

[PATCH v9 05/17] KVM: kvm_io_bus: add kvm_io_bus_get_dev() call

The kvm_io_bus framework is a nice place of holding information about various MMIO regions for kernel emulated devices. Add a call to retrieve the kvm_io_device structure which is associated with a certain MMIO address. This avoids to duplicate kvm_io_bus' knowledge of MMIO regions without having

[PATCH v9 01/17] KVM: arm/arm64: move redistributor kvm_io_devices

Logically a GICv3 redistributor is assigned to a (v)CPU, so we should aim to keep redistributor related variables out of our struct vgic_dist. Let's start by replacing the redistributor related kvm_io_device array with two members in our existing struct vgic_cpu, which are naturally per-VCPU and

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

On 12/07/16 12:33, Andre Przywara wrote: > 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

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

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