[PATCH v4 11/11] KVM: arm/arm64: timer: remove request-less vcpu kick

The timer work is only scheduled for a VCPU when that VCPU is blocked. This means we only need to wake it up, not kick (IPI) it. While calling kvm_vcpu_kick() would just do the wake up, and not kick, anyway, let's change this to avoid request-less vcpu kicks, as they're generally not a good idea

[PATCH v4 10/11] KVM: arm/arm64: PMU: remove request-less vcpu kick

Refactor PMU overflow handling in order to remove the request-less vcpu kick. Now, since kvm_vgic_inject_irq() uses vcpu requests, there should be no chance that a kick sent at just the wrong time (between the VCPU's call to kvm_pmu_flush_hwstate() and before it enters guest mode) results in a

[PATCH v4 08/11] KVM: arm/arm64: change exit request to sleep request

A request called EXIT is too generic. All requests are meant to cause exits, but different requests have different flags. Let's not make it difficult to decide if the EXIT request is correct for some case by just always providing unique requests for each case. This patch changes EXIT to SLEEP,

[PATCH v4 02/11] KVM: add kvm_request_pending

From: Radim Krčmář A first step in vcpu->requests encapsulation. Additionally, we now use READ_ONCE() when accessing vcpu->requests, which ensures we always load vcpu->requests when it's accessed. This is important as other threads can change it any time. Also, READ_ONCE()

[PATCH v4 04/11] KVM: arm/arm64: properly use vcpu requests

arm/arm64 already has one VCPU request used when setting pause, but it doesn't properly check requests in VCPU RUN. Check it and also make sure we set vcpu->mode at the appropriate time (before the check) and with the appropriate barriers. See Documentation/virtual/kvm/vcpu-requests.rst. Also make

[PATCH v4 07/11] KVM: arm/arm64: optimize VCPU RUN

We can make a small optimization by not checking the state of the power_off field on each run. This is done by treating power_off like pause, only checking it when we get the EXIT VCPU request. When a VCPU powers off another VCPU the EXIT request is already made, so we just need to make sure the

[PATCH v4 05/11] KVM: arm/arm64: replace pause checks with vcpu request checks

The current use of KVM_REQ_VCPU_EXIT for pause is fine. Even the requester clearing the request is OK, as this is the special case where the sole requesting thread and receiving VCPU are executing synchronously (see "Clearing Requests" in Documentation/virtual/kvm/vcpu-requests.rst) However,

[PATCH v4 00/11] KVM: arm/arm64: race fixes and vcpu requests

This series fixes some hard to produce races by introducing the use of vcpu requests. I've tested the series on a Mustang and compile-tested the ARM bits. Patch 3/11 adds documentation, as, at least for me, understanding vcpu request interplay with vcpu kicks and vcpu mode and the memory barriers

[PATCH v4 01/11] KVM: improve arch vcpu request defining

Marc Zyngier suggested that we define the arch specific VCPU request base, rather than requiring each arch to remember to start from 8. That suggestion, along with Radim Krcmar's recent VCPU request flag addition, snowballed into defining something of an arch VCPU request defining API. No

[RFC PATCH] kvm: arm: vgic-v3: add the emulate GICC_CTLR layout support for vmcr ctlr field.

Boot a virtual machine with the emulated GICv2 on the GICv3 hardware. Migrate the virtual machine will be successful, but the virtual machine will hang at the destination. The GICC_CTLR and ICC_CTLR_EL1 have the different layout. Currently, the set/get the VMCR interface just take vmcr ctlr field

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

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 that the kernel knows how to parse, a trace event is not generated.

[PATCH V16 11/11] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. When an SEA occurs in the guest kernel, the guest exits and is routed to kvm_handle_guest_abort(). Prior to this patch, a print

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

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 with the ARM processor error section type defined in UEFI 2.6 spec

[PATCH V16 06/11] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V16 07/11] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

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

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 the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V16 05/11] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, report the error in the kernel logs. Update fault_info[] with

[PATCH V16 01/11] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

[PATCH V16 02/11] ras: acpi/apei: cper: add support for generic data v3 structure

The ACPI 6.1 spec adds a new revision of the generic error data entry structure. Add support to handle the new structure as well as properly verify and iterate through the generic data entries. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang

[PATCH V16 03/11] cper: add timestamp print to CPER status printing

The ACPI 6.1 spec added a timestamp to the generic error data entry structure. Print the timestamp out when printing out the error information. Signed-off-by: Tyler Baicar CC: Jonathan (Zhixiong) Zhang --- drivers/firmware/efi/cper.c | 26

[PATCH V16 04/11] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar CC:

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

On Mon, May 15, 2017 at 06:51:26PM +0100, Suzuki K Poulose wrote: > On 15/05/17 18:43, Christoffer Dall wrote: > >On Mon, May 15, 2017 at 02:36:58PM +0100, Suzuki K Poulose wrote: > >>On 15/05/17 11:00, Christoffer Dall wrote: > >>>Hi Suzuki, > >>>So I don't think this change is wrong, but I

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

On 15/05/17 18:43, Christoffer Dall wrote: On Mon, May 15, 2017 at 02:36:58PM +0100, Suzuki K Poulose wrote: On 15/05/17 11:00, Christoffer Dall wrote: Hi Suzuki, So I don't think this change is wrong, but I wonder if it's sufficient. For example, I can see that this function is called from

[PATCH 02/11] KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation

kvm_host_cpu_state is a per-cpu allocation made from kvm_arch_init() used to store the host EL1 registers when KVM switches to a guest. Make it easier for ASM to generate pointers into this per-cpu memory by making it a static allocation. Signed-off-by: James Morse ---

[PATCH 10/11] firmware: arm_sdei: add support for CPU private events

Private SDE events are per-cpu, and need to be registered and enabled on each CPU. Hide this detail from the caller by adapting our {,un}register and {en,dis}able calls to send an IPI to each CPU if the event is private. CPU private events are unregistered when the CPU is powered-off, and

[PATCH 09/11] firmware: arm_sdei: Add support for CPU and system power states

When a CPU enters an idle lower-power state or is powering off, we need to mask SDE events so that no events can be delivered while we are messing with the MMU as the registered entry points won't be valid. If the system reboots, we want to unregister all events and mask the CPUs. For kexec this

[PATCH 07/11] firmware: arm_sdei: Add driver for Software Delegated Exceptions

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications. Add the code for detecting the SDEI version and the framework for registering and unregistering events.

[PATCH 11/11] KVM: arm64: Delegate support for SDEI to userspace

The Software Delegated Exception Interface allows firmware to notify the OS of system events by returning into registered handlers, even if the OS has interrupts masked. While we could support this in KVM, we would need to expose an API for the user space hypervisor to inject events, (and decide

[PATCH 08/11] arm64: kernel: Add arch-specific SDEI entry code and CPU masking

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications. Such notifications enter the kernel at the registered entry-point with the register values of the

[PATCH 06/11] dt-bindings: add devicetree binding for describing arm64 SDEI firmware

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications. Add a new devicetree binding to describe the SDE firmware interface. Signed-off-by: James Morse

[PATCH 01/11] KVM: arm64: Store vcpu on the stack during __guest_enter()

KVM uses tpidr_el2 as its private vcpu register, which makes sense for non-vhe world switch as only KVM can access this register. This means vhe Linux has to use tpidr_el1, which KVM has to save/restore as part of the host context. __guest_enter() stores the host_ctxt on the stack, do the same

[PATCH 03/11] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2

KVM calls hyp_panic() when anything unexpected happens. This may occur while a guest owns the EL1 registers. KVM stashes the vcpu pointer in tpidr_el2, which it uses to find the host context in order to restore the host EL1 registers before parachuting into the host's panic(). The host context is

[PATCH 05/11] arm64: KVM: Stop save/restoring host tpidr_el1 on VHE

Now that a VHE host uses tpidr_el2 for the cpu offset we no longer need KVM to save/restore tpidr_el1. Move this from the 'common' code into the non-vhe code. While we're at it, on VHE we don't need to save the ELR or SPSR as kernel_entry in entry.S will have pushed these onto the kernel stack,

[PATCH 04/11] arm64: alternatives: use tpidr_el2 on VHE hosts

Now that KVM uses tpidr_el2 in the same way as Linux's cpu_offset in tpidr_el1, merge the two. This saves KVM from save/restoring tpidr_el1 on VHE hosts, and allows future code to blindly access per-cpu variables without triggering world-switch. Signed-off-by: James Morse

[PATCH 00/11] arm64/firmware: Software Delegated Exception Interface

Hello! The Software Delegated Exception Interface (SDEI) is an ARM specification for registering callbacks from the platform firmware into the OS. This is intended to be used to implement firmware-first RAS notifications. The document is here:

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

On Mon, May 15, 2017 at 02:36:58PM +0100, Suzuki K Poulose wrote: > On 15/05/17 11:00, Christoffer Dall wrote: > >Hi Suzuki, > > > >On Wed, May 03, 2017 at 03:17:52PM +0100, Suzuki K Poulose wrote: > >>We yield the kvm->mmu_lock occassionaly while performing an operation > >>(e.g, unmap or

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

On 15/05/17 14:36, Suzuki K Poulose wrote: On 15/05/17 11:00, Christoffer Dall wrote: Hi Suzuki, On Wed, May 03, 2017 at 03:17:52PM +0100, Suzuki K Poulose wrote: We yield the kvm->mmu_lock occassionaly while performing an operation (e.g, unmap or permission changes) on a large area of stage2

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

On 15/05/17 11:00, Christoffer Dall wrote: Hi Suzuki, On Wed, May 03, 2017 at 03:17:52PM +0100, Suzuki K Poulose wrote: 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

Re: [PATCH v2 0/2] plug KVM ARMv7 debug leakage

On Thu, May 11, 2017 at 01:46:10PM +0100, Alex Bennée wrote: > Hi, > > This is pretty much v1 + comments from Marc and a minor re-factor of > the trap path to make it cleaner w.r.t. cp14/cp15 trapping. Thanks for these. I've applied them to kvmarm/master and cc'ed the first one to stable.

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

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 at 06:06:29PM +0200, Andrew Jones wrote: > > > VCPU halting/resuming is partially implemented with VCPU requests. > > > When

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

Hi Suzuki, On Wed, May 03, 2017 at 03:17:52PM +0100, Suzuki K Poulose wrote: > 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 >

Re: [PATCH 0/5] KVM/ARM: Fixes for 4.12-rc1

Hi Marc, On Tue, May 02, 2017 at 02:30:36PM +0100, Marc Zyngier wrote: > Here's a handful of random fixes I've queued locally that didn't have > a chance to make it in 4.11. > > The first two patches avoid stack-protector messing with the HYP code, > as this ends up being a complete disaster. >

Re: [PATCH 5/5] KVM: arm/arm64: vgic-v3: Use PREbits to infer the number of ICH_APxRn_EL2 registers

On Tue, May 02, 2017 at 02:30:41PM +0100, Marc Zyngier wrote: > The GICv3 documentation is extremely confusing, as it talks about > the number of priorities represented by the ICH_APxRn_EL2 registers, > while it should really talk about the number of preemption levels. > > This leads to a bug

Re: [PATCH 0/2] KVM: arm/arm64: Restore host physical timer access on panic

Hi James, On Tue, Apr 25, 2017 at 06:02:43PM +0100, James Morse wrote: > Hi! > > On arm64, with a single CPU when I trigger hyp_panic() with the guest > registers loaded, I get two traces: > > [ 8736.164022] Kernel panic - not syncing: HYP panic: [...] > > This is because the physical timer

Re: [PATCH] ARM: KVM: Fix tracepoint generation after move to virt/kvm/arm/

On Fri, May 12, 2017 at 11:04:52AM +0100, Marc Zyngier wrote: > Moving most of the shared code to virt/kvm/arm had for consequence > that KVM/ARM doesn't build anymore, because the code that used to > define the tracepoints is now somewhere else. > > Fix this by defining CREATE_TRACE_POINTS in