[PATCH v6 11/13] 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 v6 12/13] 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 v6 10/13] 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 v6 13/13] KVM: arm64: Emulate RAS error registers and set HCR_EL2's TERR & TEA

From: Dongjiu Geng ARMv8.2 adds a new bit HCR_EL2.TEA which routes synchronous external aborts to EL2, and adds a trap control bit HCR_EL2.TERR which traps all Non-secure EL1&0 error record accesses to EL2. This patch enables the two bits for the guest OS, guaranteeing

[PATCH v6 09/13] 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 v6 08/13] 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 v6 05/13] arm64: Unconditionally enable IESB on exception entry/return for firmware-first

ARM v8.2 has a feature to add implicit error synchronization barriers whenever the CPU enters or returns from an exception level. Add this to the features we always enable. CPUs that don't support this feature will treat the bit as RES0. This feature causes RAS errors that are not yet visible to

[PATCH v6 07/13] 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 v6 06/13] 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 v6 03/13] arm64: cpufeature: Detect CPU RAS Extentions

From: Xie XiuQi ARM's v8.2 Extentions 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. Platform

[PATCH v6 04/13] arm64: kernel: Survive corrected RAS errors notified by SError

Prior to v8.2, SError is an uncontainable fatal exception. The v8.2 RAS extensions use SError to notify software about RAS errors, these can be contained by the Error Syncronization Barrier. An ACPI system with firmware-first may use SError as its 'SEI' notification. Future patches may add code

[PATCH v6 01/13] arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early

this_cpu_has_cap() tests caps->desc not caps->matches, so it stops walking the list when it finds a 'silent' feature, instead of walking to the end of the list. Prior to v4.6's 644c2ae198412 ("arm64: cpufeature: Test 'matches' pointer to find the end of the list") we always tested desc to find

[PATCH v6 00/13] arm64/KVM: RAS & IESB for firmware first support

Hello, The aim of this series is to enable IESB to let us kick any pending RAS errors into firmware to be handled by firmware-first. v6 is a rebase onto arm64's for-next/core branch to fix the conflicts. I've picked up the Reviewed-by's from v4 that I missed on patches 7, 9 and 13, (they have

Re: [PATCH v5 00/30] ARM Scalable Vector Extension (SVE)

On Tue, Jan 09, 2018 at 07:51:20PM +0300, Yury Norov wrote: > On Mon, Jan 08, 2018 at 05:49:05PM +0300, Yury Norov wrote: > > On Tue, Oct 31, 2017 at 03:50:52PM +, Dave Martin wrote: > > > This series implements Linux kernel support for the ARM Scalable Vector > > > Extension (SVE). [1] It

Re: [PATCH v5 00/30] ARM Scalable Vector Extension (SVE)

On Mon, Jan 08, 2018 at 05:49:05PM +0300, Yury Norov wrote: > On Tue, Oct 31, 2017 at 03:50:52PM +, Dave Martin wrote: > > This series implements Linux kernel support for the ARM Scalable Vector > > Extension (SVE). [1] It supersedes the previous v3: see [3] for link > > and full cover

Re: [PATCH v4 11/19] KVM: arm/arm64: Demote HYP VA range display to being a debug feature

On Thu, Jan 04, 2018 at 06:43:26PM +, Marc Zyngier wrote: > Displaying the HYP VA information is slightly counterproductive when > using VA randomization. Turn it into a debug feature only, and adjust > the last displayed value to reflect the top of RAM instead of ~0. > > Signed-off-by: Marc

Re: [PATCH v3 00/41] Optimize KVM/ARM for VHE systems

Hi Yury, On Mon, Jan 15, 2018 at 05:14:23PM +0300, Yury Norov wrote: > On Fri, Jan 12, 2018 at 01:07:06PM +0100, Christoffer Dall wrote: > > This series redesigns parts of KVM/ARM to optimize the performance on > > VHE systems. The general approach is to try to do as little work as > > possible

Re: [PATCH v4 10/19] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state

On Thu, Jan 04, 2018 at 06:43:25PM +, Marc Zyngier wrote: > kvm_vgic_global_state is part of the read-only section, and is > usually accessed using a PC-relative address generation (adrp + add). > > It is thus useless to use kern_hyp_va() on it, and actively problematic > if kern_hyp_va()

Re: [RFC PATCH v2 1/5] iommu: Add virtio-iommu driver

Hi Jean-Philippe, please find some comments below. On 17/11/17 19:52, Jean-Philippe Brucker wrote: > The virtio IOMMU is a para-virtualized device, allowing to send IOMMU > requests such as map/unmap over virtio-mmio transport without emulating > page tables. This implementation handle ATTACH,

Re: [PATCH v3 00/41] Optimize KVM/ARM for VHE systems

Hi Christoffer, [CC Sunil Goutham ] On Fri, Jan 12, 2018 at 01:07:06PM +0100, Christoffer Dall wrote: > This series redesigns parts of KVM/ARM to optimize the performance on > VHE systems. The general approach is to try to do as little work as > possible when

Re: [PATCH v4 09/19] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag

On Thu, Jan 04, 2018 at 06:43:24PM +, Marc Zyngier wrote: > Now that we can dynamically compute the kernek/hyp VA mask, there nit: s/kernek/kernel/ > is need for a feature flag to trigger the alternative patching. is *no* need? > Let's drop the flag and everything that depends on it.

Re: [PATCH v4 08/19] arm64: KVM: Dynamically patch the kernel/hyp VA mask

On Thu, Jan 04, 2018 at 06:43:23PM +, Marc Zyngier wrote: > So far, we're using a complicated sequence of alternatives to > patch the kernel/hyp VA mask on non-VHE, and NOP out the > masking altogether when on VHE. > > THe newly introduced dynamic patching gives us the opportunity nit:

Re: [PATCH v4 06/19] arm64: insn: Add N immediate encoding

On Thu, Jan 04, 2018 at 06:43:21PM +, Marc Zyngier wrote: > We're missing the a way to generate the encoding of the N immediate, > which is only a single bit used in a number of instruction that take > an immediate. > > Signed-off-by: Marc Zyngier Acked-by: Christoffer

Re: [PATCH v4 07/19] arm64: insn: Add encoder for bitwise operations using literals

On Thu, Jan 04, 2018 at 06:43:22PM +, Marc Zyngier wrote: > We lack a way to encode operations such as AND, ORR, EOR that take > an immediate value. Doing so is quite involved, and is all about > reverse engineering the decoding algorithm described in the > pseudocode function

Re: [PATCH v4 05/19] arm64: alternatives: Add dynamic patching feature

On Thu, Jan 04, 2018 at 06:43:20PM +, Marc Zyngier wrote: > We've so far relied on a patching infrastructure that only gave us > a single alternative, without any way to finely control what gets > patched. Not sure I understand this point. Do you mean without any way to provide a range of

Re: [PATCH v4 03/19] arm64: asm-offsets: Remove potential circular dependency

On Mon, Jan 15, 2018 at 9:42 AM, Marc Zyngier wrote: > On 15/01/18 08:34, Christoffer Dall wrote: >> On Thu, Jan 04, 2018 at 06:43:18PM +, Marc Zyngier wrote: >>> So far, we've been lucky enough that none of the include files >>> that asm-offsets.c requires include

Re: [PATCH v4 04/19] arm64: alternatives: Enforce alignment of struct alt_instr

On Thu, Jan 04, 2018 at 06:43:19PM +, Marc Zyngier wrote: > We're playing a dangerous game with struct alt_instr, as we produce > it using assembly tricks, but parse them using the C structure. > We just assume that the respective alignments of the two will > be the same. > > But as we add

Re: [PATCH v4 03/19] arm64: asm-offsets: Remove potential circular dependency

On 15/01/18 08:34, Christoffer Dall wrote: > On Thu, Jan 04, 2018 at 06:43:18PM +, Marc Zyngier wrote: >> So far, we've been lucky enough that none of the include files >> that asm-offsets.c requires include asm-offsets.h. This is >> about to change, and would introduce a nasty circular

Re: [PATCH v4 03/19] arm64: asm-offsets: Remove potential circular dependency

On Thu, Jan 04, 2018 at 06:43:18PM +, Marc Zyngier wrote: > So far, we've been lucky enough that none of the include files > that asm-offsets.c requires include asm-offsets.h. This is > about to change, and would introduce a nasty circular dependency... > > Let's now guard the inclusion of

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

On Fri, Jan 12, 2018 at 06:05:23PM +, James Morse wrote: > On 15/12/17 03:30, gengdongjiu wrote: > > On 2017/12/7 14:37, gengdongjiu wrote: [...] > > (I recall someone saying migration is needed for any new KVM/cpu features, > but I > can't find the thread) > I don't know of any hard