[RFC PATCH v1] arm/arm64: vgic-new: Create dist and redist iodevs earlier

From: Vijaya Kumar K The dist and redist regions are created and registered in vgic_register_dist_iodevs() and vgic_v3_init_redist_iodev() calls for distributor and redistributor respectively when vgic_v3_map_resources() is called. This mapping of resources is done

Re: [PATCH] KVM: arm/arm64: remove kvm_vgic_*early_init() functions

Hi Andre, On 05/07/2016 15:50, Andre Przywara wrote: > kvm_vgic_early_init() and kvm_vgic_vcpu_early_init() were only used > with the old VGIC, on the new VGIC these functions do nothing. > Follow the comment in vgic-init.c and remove those functions and > their calls. > > Signed-off-by: Andre

[PATCH] KVM: arm/arm64: remove kvm_vgic_*early_init() functions

kvm_vgic_early_init() and kvm_vgic_vcpu_early_init() were only used with the old VGIC, on the new VGIC these functions do nothing. Follow the comment in vgic-init.c and remove those functions and their calls. Signed-off-by: Andre Przywara --- arch/arm/kvm/arm.c

[PATCH v8 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 v8 06/17] KVM: arm/arm64: VGIC: add refcounting for IRQs

In the moment our struct vgic_irq's are statically allocated at guest creation time. So getting a pointer to an IRQ structure is trivial and safe. LPIs are more dynamic, they can be mapped and unmapped at any time during the guest's _runtime_. In preparation for supporting LPIs we introduce

[PATCH v8 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 v8 15/17] KVM: arm64: implement ITS command queue command handlers

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

[PATCH v8 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 v8 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 v8 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 v8 10/17] KVM: arm64: introduce new KVM ITS device

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 the KVM_CREATE_DEVICE ioctl we allocate and

[PATCH v8 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 v8 00/17] KVM: arm64: GICv3 ITS emulation

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 time only smaller corrections for the KVM ITS emulation

[PATCH v8 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 v8 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 v8 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 v8 16/17] KVM: arm64: implement MSI injection in ITS emulation

When userland wants to inject a MSI into the guest, it uses the KVM_SIGNAL_MSI ioctl, which carries the doorbell address along with the payload and the device ID. We convert this into an MMIO write to the ITS translation register, so we can use the knowledge of the kvm_io_bus framework about the

[PATCH v8 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 v7 10/17] KVM: arm64: introduce new KVM ITS device

On 5 July 2016 at 09:59, Andre Przywara wrote: > Ah, OK, so you _do_ the address setup _after_ the INIT. > My understanding of the KVM API was that this isn't allowed, as with the > INIT _everything_ should have been setup. kvmtool works this way. > > So we obviously can't

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

On 05/07/2016 10:59, Andre Przywara wrote: > Hi Eric, > > thank you very much for the elaborate explanation! > > On 05/07/16 08:40, Auger Eric wrote: >> Hi Andre, >> On 04/07/2016 19:40, Andre Przywara wrote: >>> Hi Eric, >>> >>> On 04/07/16 16:00, Auger Eric wrote: Hi Peter, On

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

Hi Eric, thank you very much for the elaborate explanation! On 05/07/16 08:40, Auger Eric wrote: > Hi Andre, > On 04/07/2016 19:40, Andre Przywara wrote: >> Hi Eric, >> >> On 04/07/16 16:00, Auger Eric wrote: >>> Hi Peter, >>> >>> On 04/07/2016 16:32, Peter Maydell wrote: On 4 July 2016 at

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

Hi Andre, On 04/07/2016 19:40, Andre Przywara wrote: > Hi Eric, > > On 04/07/16 16:00, Auger Eric wrote: >> Hi Peter, >> >> On 04/07/2016 16:32, Peter Maydell wrote: >>> On 4 July 2016 at 15:27, Auger Eric wrote: Andre, On 04/07/2016 16:05, Andre Przywara

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

Hi Andre, On 04/07/2016 19:40, Andre Przywara wrote: > Hi Eric, > > On 04/07/16 16:00, Auger Eric wrote: >> Hi Peter, >> >> On 04/07/2016 16:32, Peter Maydell wrote: >>> On 4 July 2016 at 15:27, Auger Eric wrote: Andre, On 04/07/2016 16:05, Andre Przywara