Re: [PATCH 26/37] KVM: arm64: Prepare to handle traps on deferred AArch32 sysregs

On Thu, Oct 12, 2017 at 12:41:30PM +0200, Christoffer Dall wrote: > Handle accesses to any AArch32 EL1 system registers where we can defer > saving and restoring them to vcpu_load and vcpu_put, and which are > stored in special EL2 registers only used support 32-bit guests. > > Signed-off-by:

Re: [PATCH 25/37] KVM: arm64: Prepare to handle traps on remaining deferred EL1 sysregs

On Thu, Oct 12, 2017 at 12:41:29PM +0200, Christoffer Dall wrote: > Handle accesses during traps to any remaining EL1 registers which can be > deferred to vcpu_load and vcpu_put, by either accessing them directly on > the physical CPU when the latest version is stored there, or by > synchronizing

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On 13 November 2017 at 16:14, Andrew Jones wrote: > On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote: >> I'm thinking this is analogous to migrating a VM that uses an irqchip in >> userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My >> feeling is

Re: [PATCH 23/37] KVM: arm64: Prepare to handle traps on deferred VM sysregs

On Thu, Oct 12, 2017 at 12:41:27PM +0200, Christoffer Dall wrote: > When we defer the save/restore of system registers to vcpu_load and > vcpu_put, we need to take care of the emulation code that handles traps > to these registers, since simply reading the memory array will return > stale data. >

Re: [PATCH 22/37] KVM: arm64: Change 32-bit handling of VM system registers

On Thu, Oct 12, 2017 at 12:41:26PM +0200, Christoffer Dall wrote: > We currently handle 32-bit accesses to trapped VM system registers using > the 32-bit index into the coproc array on the vcpu structure, which is a > union of the coprog array and the sysreg array. coproc > > Since all the

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Mon, Nov 13, 2017 at 12:29:46PM +0100, Christoffer Dall wrote: > On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: > > Hi guys, > > > > On 19/10/17 15:57, James Morse wrote: > > > Known issues: > > [...] > > > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how

Re: [PATCH v2 3/3] kvm: arm64: handle single-step of userspace mmio instructions

Julien Thierry writes: > Hi Alex, > > On 09/11/17 17:00, Alex Bennée wrote: >> The system state of KVM when using userspace emulation is not complete >> until we return into KVM_RUN. To handle mmio related updates we wait >> until they have been committed and then

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On 13 November 2017 at 11:29, Christoffer Dall wrote: > I'm thinking this is analogous to migrating a VM that uses an irqchip in > userspace and has set the IRQ or FIQ lines using KVM_IRQ_LINE. My > feeling is that this is also not supported today. Oops, yes, we completely

Re: [PATCH v4 00/21] SError rework + RAS for firmware first support

On Thu, Nov 09, 2017 at 06:14:56PM +, James Morse wrote: > Hi guys, > > On 19/10/17 15:57, James Morse wrote: > > Known issues: > [...] > > * KVM-Migration: VDISR_EL2 is exposed to userspace as DISR_EL1, but how > > should > >HCR_EL2.VSE or VSESR_EL2 be migrated when the guest has an

Re: [PATCH v2 3/3] kvm: arm64: handle single-step of userspace mmio instructions

Hi Alex, On 09/11/17 17:00, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return into KVM_RUN. To handle mmio related updates we wait until they have been committed and then schedule our KVM_EXIT_DEBUG. The kvm_arm_handle_step_debug() helper

Re: [PATCH v2 2/3] kvm: arm64: handle single-stepping trapped instructions

On 09/11/17 17:00, Alex Bennée wrote: If we are using guest debug to single-step the guest we need to ensure we exit after emulating the instruction. This only affects instructions completely emulated by the kernel. For userspace emulated instructions we need to exit and return to complete the

Re: [PATCH v4 15/13] firmware: arm_sdei: be more robust against cpu-hotplug

On Wed, Nov 08, 2017 at 04:06:24PM +, James Morse wrote: > dpm_suspend() calls the freeze/thaw callbacks for hibernate before > disable_non_bootcpus() takes down secondaries. > > This leads to a fun race where the freeze/thaw callbacks reset the > SDEI interface (as we may be restoring a

Re: [PATCH v2 1/3] kvm: arm debug: introduce helper for single-step

On 09/11/17 17:00, Alex Bennée wrote: After emulating instructions we may want return to user-space to handle a single-step. If single-step is enabled the helper set the run structure for return and returns true. Signed-off-by: Alex Bennée With the fixup:

[PULL 25/27] KVM: arm/arm64: GICv4: Theory of operations

From: Marc Zyngier Yet another braindump so I can free some cells... Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall --- virt/kvm/arm/vgic/vgic-v4.c |

[PULL 16/27] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE

From: Marc Zyngier There is no need to perform an INV for each interrupt when updating multiple interrupts. Instead, we can rely on the final VINVALL that gets sent to the ITS to do the work for all of them. Acked-by: Christoffer Dall Reviewed-by: Eric

[PULL 02/27] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

From: Eric Auger We want to reuse the core of the map/unmap functions for IRQ forwarding. Let's move the computation of the hwirq in kvm_vgic_map_phys_irq and pass the linux IRQ as parameter. the host_irq is added to struct vgic_irq. We introduce kvm_vgic_map/unmap_irq

[PULL 20/27] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync

From: Marc Zyngier The redistributor needs to be told which vPE is about to be run, and tells us whether there is any pending VLPI on exit. Let's add the scheduling calls to the vgic flush/sync functions, allowing the VLPIs to be delivered to the guest. Reviewed-by:

[PULL 13/27] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI

From: Marc Zyngier Handling CLEAR is pretty easy. Just ask the ITS driver to clear the corresponding pending bit (which will turn into a CLEAR command on the physical side). Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier

[PULL 05/27] KVM: arm/arm64: vITS: Add MSI translation helpers

From: Marc Zyngier The whole MSI injection process is fairly monolithic. An MSI write gets turned into an injected LPI in one swift go. But this is actually a more fine-grained process: - First, a virtual ITS gets selected using the doorbell address - Then the

[PULL 26/27] KVM: arm/arm64: Fix GICv4 ITS initialization issues

We should only try to initialize GICv4 data structures on a GICv4 capable system. Move the vgic_supports_direct_msis() check inito vgic_v4_init() so that any KVM VGIC initialization path does not fail on non-GICv4 systems. Also be slightly more strict in the checking of the return value in

[PULL 04/27] KVM: arm/arm64: vgic: Move kvm_vgic_destroy call around

From: Marc Zyngier The way we call kvm_vgic_destroy is a bit bizarre. We call it *after* having freed the vcpus, which sort of defeats the point of cleaning up things before that point. Let's move kvm_vgic_destroy towards the beginning of kvm_arch_destroy_vm, which seems

[PULL 18/27] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

From: Marc Zyngier When a vPE is not running, a VLPI being made pending results in a doorbell interrupt being delivered. Let's handle this interrupt and update the pending_last flag that indicates that VLPIs are pending. The corresponding vcpu is also kicked into action.

[PULL 15/27] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

From: Marc Zyngier Upon updating a property, we propagate it all the way to the physical ITS, and ask for an INV command to be executed there. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall

[PULL 01/27] KVM: arm/arm64: register irq bypass consumer on ARM/ARM64

From: Eric Auger This patch selects IRQ_BYPASS_MANAGER and HAVE_KVM_IRQ_BYPASS configs for ARM/ARM64. kvm_arch_has_irq_bypass() now is implemented and returns true. As a consequence the irq bypass consumer will be registered for ARM/ARM64 with the forwarding callbacks: -

[PULL 06/27] KVM: arm/arm64: vITS: Add a helper to update the affinity of an LPI

From: Marc Zyngier In order to help integrating the vITS code with GICv4, let's add a new helper that deals with updating the affinity of an LPI, which will later be augmented with super duper extra GICv4 goodness. Reviewed-by: Christoffer Dall

[PULL 11/27] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

From: Marc Zyngier When freeing an LPI (on a DISCARD command, for example), we need to unmap the VLPI down to the physical ITS level. Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall

[PULL 19/27] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source

From: Marc Zyngier The doorbell interrupt is only useful if the vcpu is blocked on WFI. In all other cases, recieving a doorbell interrupt is just a waste of cycles. So let's only enable the doorbell if a vcpu is getting blocked, and disable it when it is unblocked. This

[PULL 17/27] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint

From: Marc Zyngier When a vPE exits, the pending_last flag is set when there are pending VLPIs stored in the pending table. Similarily, this flag will be set when a doorbell interrupt fires, as it indicates the same condition. Let's update kvm_vgic_vcpu_pending_irq() to

[PULL 22/27] KVM: arm/arm64: GICv4: Prevent a VM using GICv4 from being saved

From: Marc Zyngier The GICv4 architecture doesn't make it easy for save/restore to work, as it doesn't give any guarantee that the pending state is written into the pending table. So let's not take any chance, and let's return an error if we encounter any LPI that has the

[PULL 00/27] KVM/ARM GICv4 Support for v4.15

Hi Paolo and Radim, Here is the second pull request for KVM/ARM for v4.15. These changes introduce GICv4 support in KVM/ARM, allowing direct injection of LPIs from devices generating MSIs into VMs. The changes rely on irqchip infrastructure for GICv4 already merged in tip:irq/core. The pull

[PULL 03/27] KVM: arm: Select ARM_GIC_V3 and ARM_GIC_V3_ITS

From: Marc Zyngier The GICv4 support introduces a hard dependency between the KVM core and the ITS infrastructure. arm64 already selects it at the architecture level, but 32bit doesn't. In order to avoid littering the kernel with #ifdefs, let's just select the whole of the

[PULL 12/27] KVM: arm/arm64: GICv4: Propagate affinity changes to the physical ITS

From: Marc Zyngier When the guest issues an affinity change, we need to tell the physical ITS that we're now targetting a new vcpu. This is done by extracting the current mapping, updating the target, and reapplying the mapping. Reviewed-by: Christoffer Dall

[PULL 10/27] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

From: Marc Zyngier If the guest issues an INT command targetting a VLPI, let's call into the irq_set_irqchip_state() helper to make it pending on the physical side. This works just as well if userspace decides to inject an interrupt using the normal userspace API...

[PULL 08/27] KVM: arm/arm64: GICv4: Add init/teardown of the per-VM vPE irq domain

From: Marc Zyngier In order to control the GICv4 view of virtual CPUs, we rely on an irqdomain allocated for that purpose. Let's add a couple of helpers to that effect. At the same time, the vgic data structures gain new fields to track all this... erm... wonderful stuff.

[PULL 09/27] KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass

From: Marc Zyngier Let's use the irq bypass mechanism also used for x86 posted interrupts to intercept the virtual PCIe endpoint configuration and establish our LPI->VLPI mapping. Reviewed-by: Christoffer Dall Signed-off-by: Marc Zyngier

[PULL 07/27] KVM: arm/arm64: GICv4: Add property field and per-VM predicate

From: Marc Zyngier Add a new has_gicv4 field in the global VGIC state that indicates whether the HW is GICv4 capable, as a per-VM predicate indicating if there is a possibility for a VM to support direct injection (the above being true and the VM having an ITS).

[PULL 21/27] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

From: Marc Zyngier In order for VLPIs to be delivered to the guest, we must make sure that the virtual cpuif is always enabled, irrespective of the presence of virtual interrupt in the LRs. Acked-by: Christoffer Dall Reviewed-by: Eric Auger

[PULL 23/27] KVM: arm/arm64: GICv4: Prevent userspace from changing doorbell affinity

From: Marc Zyngier We so far allocate the doorbell interrupts without taking any special measure regarding the affinity of these interrupts. We simply move them around as required when the vcpu gets scheduled on a different CPU. But that's counting without userspace (and

[PULL 14/27] KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE

From: Marc Zyngier The current implementation of MOVALL doesn't allow us to call into the core ITS code as we hold a number of spinlocks. Let's try a method used in other parts of the code, were we copy the intids of the candicate interrupts, and then do whatever we need