[PATCH v3 20/20] KVM: arm64: Take any host SError before entering the guest

On VHE systems KVM masks SError before switching the VBAR value. Any host RAS error that the CPU knew about before world-switch may become pending as an SError during world-switch, and only be taken once we enter the guest. Until KVM can take RAS SErrors during world switch, add an ESB to force

[PATCH v3 19/20] KVM: arm64: Handle RAS SErrors from EL2 on guest exit

We expect to have firmware-first handling of RAS SErrors, with errors notified via an APEI method. For systems without firmware-first, add some minimal handling to KVM. There are two ways KVM can take an SError due to a guest, either may be a RAS error: we exit the guest due to an SError routed

[PATCH v3 18/20] KVM: arm64: Handle RAS SErrors from EL1 on guest exit

We expect to have firmware-first handling of RAS SErrors, with errors notified via an APEI method. For systems without firmware-first, add some minimal handling to KVM. There are two ways KVM can take an SError due to a guest, either may be a RAS error: we exit the guest due to an SError routed

[PATCH v3 14/20] arm64: kernel: Prepare for a DISR user

KVM would like to consume any pending SError (or RAS error) after guest exit. Today it has to unmask SError and use dsb+isb to synchronise the CPU. With the RAS extensions we can use ESB to synchronise any pending SError. Add the necessary macros to allow DISR to be read and converted to an ESR.

[PATCH v3 17/20] KVM: arm64: Save ESR_EL2 on guest SError

When we exit a guest due to an SError the vcpu fault info isn't updated with the ESR. Today this is only done for traps. The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's fault_info with the ESR on SError so that handle_exit() can determine if this was a RAS SError and

[PATCH v3 11/20] arm64: cpufeature: Detect CPU RAS Extentions

From: Xie XiuQi ARM's v8.2 Extensions add support for Reliability, Availability and Serviceability (RAS). On CPUs with these extensions system software can use additional barriers to isolate errors and determine if faults are pending. Add cpufeature detection and a barrier

[PATCH v3 10/20] arm64: entry.S: move SError handling into a C function for future expansion

From: Xie XiuQi Today SError is taken using the inv_entry macro that ends up in bad_mode. SError can be used by the RAS Extensions to notify either the OS or firmware of CPU problems, some of which may have been corrected. To allow this handling to be added, add a

[PATCH v3 15/20] KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2.

Prior to v8.2's RAS Extensions, the HCR_EL2.VSE 'virtual SError' feature generated an SError with an implementation defined ESR_EL1.ISS, because we had no mechanism to specify the ESR value. On Juno this generates an all-zero ESR, the most significant bit 'ISV' is clear indicating the remainder

[PATCH v3 16/20] KVM: arm64: Save/Restore guest DISR_EL1

If we deliver a virtual SError to the guest, the guest may defer it with an ESB instruction. The guest reads the deferred value via DISR_EL1, but the guests view of DISR_EL1 is re-mapped to VDISR_EL2 when HCR_EL2.AMO is set. Add the KVM code to save/restore VDISR_EL2, and make it accessible to

[PATCH v3 09/20] KVM: arm/arm64: mask/unmask daif around VHE guests

Non-VHE systems take an exception to EL2 in order to world-switch into the guest. When returning from the guest KVM implicitly restores the DAIF flags when it returns to the kernel at EL1. With VHE none of this exception-level jumping happens, so KVMs world-switch code is exposed to the host

[PATCH v3 08/20] arm64: entry.S: convert elX_irq

Following our 'dai' order, irqs should be processed with debug and serror exceptions unmasked. Add a helper to unmask these two, (and fiq for good measure). Signed-off-by: James Morse --- arch/arm64/include/asm/assembler.h | 4 arch/arm64/kernel/entry.S | 4

[PATCH v3 02/20] arm64: introduce an order for exceptions

Currently SError is always masked in the kernel. To support RAS exceptions using SError on hardware with the v8.2 RAS Extensions we need to unmask SError as much as possible. Let's define an order for masking and unmasking exceptions. 'dai' is memorable and effectively what we have today.

[PATCH v3 03/20] arm64: Move the async/fiq helpers to explicitly set process context flags

Remove the local_{async,fiq}_{en,dis}able macros as they don't respect our newly defined order and are only used to set the flags for process context when we bring CPUs online. Add a helper to do this. The IRQ flag varies as we want it masked on the boot CPU until we are ready to handle

[PATCH v3 00/20] SError rework + RAS for firmware first support

Hello, The aim of this series is to enable IESB and add ESB-instructions to let us kick any pending RAS errors into firmware to be handled by firmware-first. Not all systems will have this firmware, so these RAS errors will become pending SErrors. We should take these as quickly as possible and

[PATCH v3 07/20] arm64: entry.S convert el0_sync

el0_sync also unmasks exceptions on a case-by-case basis, debug exceptions are enabled, unless this was a debug exception. Irqs are unmasked for some exception types but not for others. el0_dbg should run with everything masked to prevent us taking a debug exception from do_debug_exception. For

[PATCH v3 06/20] arm64: entry.S: convert el1_sync

el1_sync unmasks exceptions on a case-by-case basis, debug exceptions are unmasked, unless this was a debug exception. IRQs are unmasked for instruction and data aborts only if the interrupted context had irqs unmasked. Following our 'dai' order, el1_dbg should run with everything masked. For the

[PATCH v3 04/20] arm64: Mask all exceptions during kernel_exit

To take RAS Exceptions as quickly as possible we need to keep SError unmasked as much as possible. We need to mask it during kernel_exit as taking an error from this code will overwrite the exception-registers. Adding a naked 'disable_daif' to kernel_exit causes a performance problem for

[PATCH v3 01/20] arm64: explicitly mask all exceptions

There are a few places where we want to mask all exceptions. Today we do this in a piecemeal fashion, typically we expect the caller to have masked irqs and the arch code masks debug exceptions, ignoring SError which is probably masked. Make it clear that 'mask all exceptions' is the intention by

[PATCH v3 05/20] arm64: entry.S: Remove disable_dbg

enable_step_tsk is the only user of disable_dbg, which doesn't respect our 'dai' order for exception masking. enable_step_tsk may enable single-step, so previously needed to mask debug exceptions to prevent us from single-stepping kernel_exit. enable_step_tsk is called at the end of the

Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector length

On Thu, Oct 05, 2017 at 05:53:34PM +0100, Catalin Marinas wrote: > On Thu, Oct 05, 2017 at 05:42:29PM +0100, Dave P Martin wrote: > > On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote: > > > On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote: > > > > On Wed, Sep 13, 2017

Re: [PATCH v2 26/28] arm64/sve: Add documentation

On Thu, Oct 05, 2017 at 05:39:24PM +0100, Szabolcs Nagy wrote: > On 31/08/17 18:00, Dave Martin wrote: [...] > > + PR_SVE_SET_VL_ONEXEC > > + > > + Defer the requested vector length change until the next execve(). > > + This allows launching of a new program with a different vector

Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector length

On Thu, Oct 05, 2017 at 05:42:29PM +0100, Dave P Martin wrote: > On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote: > > On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote: > > > On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote: > > > > On Thu, Aug 31, 2017

Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector length

On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote: > On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote: > > On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote: > > > On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote: > > > > This patch implements

Re: [PATCH v2 26/28] arm64/sve: Add documentation

On 31/08/17 18:00, Dave Martin wrote: > +prctl(PR_SVE_SET_VL, unsigned long arg) > + > +Sets the vector length of the calling thread and related flags, where > +arg == vl | flags. > + > +vl is the desired vector length, where sve_vl_valid(vl) must be true. > + > +flags: > + > +

Re: [PATCH v2 11/28] arm64/sve: Core task context handling

On Tue, Oct 03, 2017 at 12:33:03PM +0100, Dave P Martin wrote: > On Wed, Sep 13, 2017 at 07:33:25AM -0700, Catalin Marinas wrote: > > On Thu, Aug 31, 2017 at 06:00:43PM +0100, Dave P Martin wrote: > > > +/* > > > + * Handle SVE state across fork(): > > > + * > > > + * dst and src must not end up

Re: [PATCH v2 10/28] arm64/sve: Low-level CPU setup

On Thu, Oct 05, 2017 at 12:04:12PM +0100, Suzuki K Poulose wrote: > On 05/10/17 11:47, Dave Martin wrote: [...] > >>>On Thu, Aug 31, 2017 at 06:00:42PM +0100, Dave P Martin wrote: > diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S > index 877d42f..dd22ef2 100644 > ---

Re: [PATCH v2 10/28] arm64/sve: Low-level CPU setup

On 05/10/17 11:47, Dave Martin wrote: On Wed, Sep 13, 2017 at 08:21:11PM +0100, Dave Martin wrote: On Wed, Sep 13, 2017 at 06:32:06AM -0700, Catalin Marinas wrote: On Thu, Aug 31, 2017 at 06:00:42PM +0100, Dave P Martin wrote: diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index

Re: [PATCH v2 10/28] arm64/sve: Low-level CPU setup

On Wed, Sep 13, 2017 at 08:21:11PM +0100, Dave Martin wrote: > On Wed, Sep 13, 2017 at 06:32:06AM -0700, Catalin Marinas wrote: > > On Thu, Aug 31, 2017 at 06:00:42PM +0100, Dave P Martin wrote: > > > diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S > > > index 877d42f..dd22ef2 100644 > >

Re: [PATCH 5/5] KVM: arm/arm64: kvm_arch_vcpu_runnable: don't miss injected irqs

On 29/09/17 12:30, Andrew Jones wrote: > When the vPMU is in use if a VCPU's perf event overflow handler > were to fire after the VCPU started waiting, then the wake up > done by the kvm_vcpu_kick() call in the handler would do nothing, > as no "pmu overflow" state is checked in

Re: [PATCH 6/5] KVM: arm/arm64: make kvm_vgic_vcpu_pending_irq static

On 02/10/17 09:31, Andrew Jones wrote: > Now that the only caller of kvm_vgic_vcpu_pending_irq() is in the > vgic code, let's make it private in order to discourage it's use > outside, as checking the IRQ_PENDING VCPU request is likely the > right thing for non-vgic code to do. Also, remove a vgic

Re: [PATCH 4/5] KVM: arm/arm64: improve kvm_arch_vcpu_runnable

On 29/09/17 12:30, Andrew Jones wrote: > Conceptually, kvm_arch_vcpu_runnable() should be "not waiting, > or waiting for interrupts and interrupts are pending", > > !waiting-uninterruptable && > (!waiting-for-interrupts || interrupts-pending) > > but the implementation was only > >

Re: [PATCH 3/5] KVM: arm/arm64: factor out common wfe/wfi emulation code

On 29/09/17 12:30, Andrew Jones wrote: > Before we add more common code to the wfi emulation, let's first > factor out everything common. > > Signed-off-by: Andrew Jones > --- > arch/arm/include/asm/kvm_host.h | 2 ++ > arch/arm/kvm/handle_exit.c| 14

Re: [PATCH 2/5] KVM: arm/arm64: replace power_off with mp_state=STOPPED

On 29/09/17 12:30, Andrew Jones wrote: > This prepares for more MP states to be used. > > Signed-off-by: Andrew Jones > --- > arch/arm/include/asm/kvm_host.h | 6 -- > arch/arm64/include/asm/kvm_host.h | 6 -- > virt/kvm/arm/arm.c| 26

Re: [PATCH 1/5] KVM: arm/arm64: tidy 'should sleep' conditions

On 29/09/17 12:30, Andrew Jones wrote: > Introduce vcpu_should_sleep() in order to tidy several places up > that the compound 'power_off || pause' condition is used. > > Signed-off-by: Andrew Jones > --- > virt/kvm/arm/arm.c | 18 +++--- > 1 file changed, 11