Re: [PATCH v2 07/11] KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs

On Tue, May 16, 2017 at 02:39:18PM +0200, Auger Eric wrote: > Hi Jean, Christoffer, > > On 16/05/2017 13:23, Jean-Philippe Brucker wrote: > > Hi, > > > > On 09/05/17 09:56, Christoffer Dall wrote: > >> Instead of waiting with registering KVM iodevs until the first VCPU is > >> run, we can

[PATCH v2 5/9] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace

First we define an ABI using the vcpu devices that lets userspace set the interrupt numbers for the various timers on both the 32-bit and 64-bit KVM/ARM implementations. Second, we add the definitions for the groups and attributes introduced by the above ABI. (We add the PMU define on the 32-bit

[PATCH v2 4/9] KVM: arm/arm64: Move timer IRQ default init to arch_timer.c

We currently initialize the arch timer IRQ numbers from the reset code, presumably because we once intended to model multiple CPU or SoC types from within the kernel and have hard-coded reset values in the reset code. As we are moving towards userspace being in charge of more fine-grained CPU

[PATCH v2 9/9] KVM: arm/arm64: Don't assume initialized vgic when setting PMU IRQ

The PMU IRQ number is set through the VCPU device's KVM_SET_DEVICE_ATTR ioctl handler for the KVM_ARM_VCPU_PMU_V3_IRQ attribute, but there is no enforced or stated requirement that this must happen after initializing the VGIC. As a result, calling vgic_valid_spi() which relies on the nr_spis

[PATCH v2 2/9] KVM: arm: Handle VCPU device attributes in guest.c

As we are about to support VCPU attributes to set the timer IRQ numbers in guest.c, move the static inlines for the VCPU attributes handlers from the header file to guest.c. Signed-off-by: Christoffer Dall --- arch/arm/include/asm/kvm_host.h | 22 +++--

[PATCH v2 6/9] KVM: arm/arm64: Introduce an allocator for in-kernel irq lines

Having multiple devices being able to signal the same interrupt line is very confusing and almost certainly guarantees a configuration error. Therefore, introduce a very simple allocator which allows a device to claim an interrupt line from the vgic for a given VM. Signed-off-by: Christoffer

[PATCH v2 1/9] KVM: arm64: Allow creating the PMU without the in-kernel GIC

Since we got support for devices in userspace which allows reporting the PMU overflow output status to userspace, we should actually allow creating the PMU on systems without an in-kernel irqchip, which in turn requires us to slightly clarify error codes for the ABI and move things around for the

[PATCH v2 8/9] KVM: arm/arm64: Disallow userspace control of in-kernel IRQ lines

When injecting an IRQ to the VGIC, you now have to present an owner token for that IRQ line to show that you are the owner of that line. IRQ lines driven from userspace or via an irqfd do not have an owner and will simply pass a NULL pointer. Also get rid of the unused kvm_vgic_inject_mapped_irq

[PATCH v2 7/9] KVM: arm/arm64: Check if irq lines to the GIC are already used

We check if other in-kernel devices have already been connected to the GIC for a particular interrupt line when possible. For the PMU, we can do this whenever setting the PMU interrupt number from userspace. For the timers, we have to wait until we try to enable the timer, because we have a

[PATCH v2 0/9] Userspace timer IRQ number control and PMU with userspace-gic

So far we have been getting away with letting the kernel choosing interrupt numbers for the timers in the kernel and we have crossed our fingers in hoping that the DT/ACPI provided by userspace matches with the interrupt number we use in the kernel for a given VCPU type. But as we are generally

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On 5/16/2017 10:55 AM, Borislav Petkov wrote: On Tue, May 16, 2017 at 10:44:43AM -0600, Baicar, Tyler wrote: I meant to respond to this comment after I sent the v16 patch series, but you beat me to it :) These prefixes are common to all the GHES/CPER printing to the kernel logs. I don't mean

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On Tue, May 16, 2017 at 10:44:43AM -0600, Baicar, Tyler wrote: > I meant to respond to this comment after I sent the v16 patch series, but > you beat me to it :) > > These prefixes are common to all the GHES/CPER printing to the kernel logs. I don't mean that - I meant to remove them from this

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On 5/16/2017 8:29 AM, Borislav Petkov wrote: On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match

Re: [PATCH V16 10/11] trace, ras: add ARM processor error trace event

On Mon, May 15, 2017 at 03:27:59PM -0600, Tyler Baicar wrote: > Currently there are trace events for the various RAS > errors with the exception of ARM processor type errors. > Add a new trace event for such errors so that the user > will know when they occur. These trace events are > consistent

Re: [PATCH V16 09/11] ras: acpi / apei: generate trace event for unrecognized CPER section

On Mon, May 15, 2017 at 03:27:58PM -0600, Tyler Baicar wrote: > The UEFI spec includes non-standard section type support in the > Common Platform Error Record. This is defined in section N.2.3 of > UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match any > section type

Re: [PATCH V16 08/11] efi: print unrecognized CPER section

On Mon, May 15, 2017 at 03:27:57PM -0600, Tyler Baicar wrote: > UEFI spec allows for non-standard section in Common Platform Error > Record. This is defined in section N.2.3 of UEFI version 2.5. > > Currently if the CPER section's type (UUID) does not match with > one of the section types that

Re: [PATCH v3 0/2] kvm: arm/arm64: Fixes for race conditions

On Tue, May 16, 2017 at 11:01:54AM +0100, Suzuki K Poulose wrote: > On 16/05/17 10:53, Christoffer Dall wrote: > >On Tue, May 16, 2017 at 10:34:53AM +0100, Suzuki K Poulose wrote: > >>The patches fixes race conditions in stage2 pgd accesses. > >> > >>Patch 1 is a fix up for the patch which has

Re: [PATCH v2 07/11] KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs

Hi Jean, Christoffer, On 16/05/2017 13:23, Jean-Philippe Brucker wrote: > Hi, > > On 09/05/17 09:56, Christoffer Dall wrote: >> Instead of waiting with registering KVM iodevs until the first VCPU is >> run, we can actually create the iodevs when the redist base address is >> set. The only

Re: [PATCH v2 07/11] KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs

Hi, On 09/05/17 09:56, Christoffer Dall wrote: > Instead of waiting with registering KVM iodevs until the first VCPU is > run, we can actually create the iodevs when the redist base address is > set. The only downside is that we must now also check if we need to do > this for VCPUs which are

Re: [PATCH 5/5] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace

On Tue, May 16, 2017 at 08:54:21AM +0200, Christoffer Dall wrote: > Hi Marc, > > On Thu, May 04, 2017 at 01:22:25PM +0200, Christoffer Dall wrote: > > On Thu, May 04, 2017 at 11:54:06AM +0100, Marc Zyngier wrote: > > > On 04/05/17 10:59, Christoffer Dall wrote: > > > > On Thu, May 04, 2017 at

Re: [PATCH v3 04/10] KVM: arm/arm64: use vcpu request in kvm_arm_halt_vcpu

On Tue, May 16, 2017 at 04:17:33AM +0200, Andrew Jones wrote: > On Mon, May 15, 2017 at 01:14:42PM +0200, Christoffer Dall wrote: > > On Tue, May 09, 2017 at 07:02:51PM +0200, Andrew Jones wrote: > > > On Sat, May 06, 2017 at 08:08:09PM +0200, Christoffer Dall wrote: > > > > On Wed, May 03, 2017

[PATCH v2 3/3] KVM: arm/arm64: Simplify active_change_prepare and plug race

We don't need to stop a specific VCPU when changing the active state, because private IRQs can only be modified by a running VCPU for the VCPU itself and it is therefore already stopped. However, it is also possible for two VCPUs to be modifying the active state of SPIs at the same time, which

[PATCH v2 2/3] KVM: arm/arm64: Separate guest and uaccess writes to dist {sc}active

Factor out the core register modifier functionality from the entry points from the register description table, and only call the prepare/finish functions from the guest path, not the uaccess path. Signed-off-by: Christoffer Dall --- virt/kvm/arm/vgic/vgic-mmio-v2.c | 6 +++--

[PATCH v2 0/3] Fix race condition and simplify vgic active handler

This is a small series that reworks a problem in a previously submitted patch [1]. The previous patch version did not consider that userspace accesses already hold the KVM mutex and therefore end up in deadlock. These patches therefore introduces uaccess read/write functions for the GICv2 MMIO

[PATCH v2 1/3] KVM: arm/arm64: Allow GICv2 to supply a uaccess register function

We are about to differentiate between writes from a VCPU and from userspace to the GIC's GICD_ISACTIVER and GICD_ICACTIVER registers due to different synchronization requirements. Expand the macro to define a register description for the GIC to take uaccess functions as well. Signed-off-by:

Re: [PATCH v3 0/2] kvm: arm/arm64: Fixes for race conditions

On 16/05/17 10:53, Christoffer Dall wrote: On Tue, May 16, 2017 at 10:34:53AM +0100, Suzuki K Poulose wrote: The patches fixes race conditions in stage2 pgd accesses. Patch 1 is a fix up for the patch which has already been pushed to kvmarm/master. Patch 2 fixes a case where stage2 PGD could

Re: [PATCH v3 0/2] kvm: arm/arm64: Fixes for race conditions

On Tue, May 16, 2017 at 10:34:53AM +0100, Suzuki K Poulose wrote: > The patches fixes race conditions in stage2 pgd accesses. > > Patch 1 is a fix up for the patch which has already been pushed to > kvmarm/master. > > Patch 2 fixes a case where stage2 PGD could be free'd when we release > the

[PATCH v3 0/2] kvm: arm/arm64: Fixes for race conditions

The patches fixes race conditions in stage2 pgd accesses. Patch 1 is a fix up for the patch which has already been pushed to kvmarm/master. Patch 2 fixes a case where stage2 PGD could be free'd when we release the kvm->mmu_lock to prevent VCPU starvation. Applies on kvmarm/master tree Changes

[PATCH v3 2/2] kvm: arm/arm64: Fix use after free of stage2 page table

We yield the kvm->mmu_lock occassionaly while performing an operation (e.g, unmap or permission changes) on a large area of stage2 mappings. However this could possibly cause another thread to clear and free up the stage2 page tables while we were waiting for regaining the lock and thus the

Re: [PATCH 5/5] KVM: arm/arm64: Allow setting the timer IRQ numbers from userspace

Hi Marc, On Thu, May 04, 2017 at 01:22:25PM +0200, Christoffer Dall wrote: > On Thu, May 04, 2017 at 11:54:06AM +0100, Marc Zyngier wrote: > > On 04/05/17 10:59, Christoffer Dall wrote: > > > On Thu, May 04, 2017 at 10:34:32AM +0100, Marc Zyngier wrote: > > >> On 03/05/17 19:33, Christoffer Dall