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

Hi James, On 2017/12/7 3:04, James Morse wrote: > Hi gengdongjiu, > > On 06/12/17 10:26, gengdongjiu wrote: >> On 2017/11/15 0:00, James Morse wrote: + * error has not been propagated + */ + run->exit_reason = KVM_EXIT_EXCEPTION; +

Re: [PATCH v5 15/30] arm64/sve: Signal handling support

On Tue, Oct 31, 2017 at 8:51 AM, Dave Martin wrote: > This patch implements support for saving and restoring the SVE > registers around signals. > > A fixed-size header struct sve_context is always included in the > signal frame encoding the thread's vector length at the time

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

Hi gengdongjiu, On 06/12/17 10:26, gengdongjiu wrote: > On 2017/11/15 0:00, James Morse wrote: >>> +* error has not been propagated >>> +*/ >>> + run->exit_reason = KVM_EXIT_EXCEPTION; >>> + run->ex.exception = ESR_ELx_EC_SERROR; >>> +

[PATCH v5 16/16] arm64: sdei: Add trampoline code for remapping the kernel

When CONFIG_UNMAP_KERNEL_AT_EL0 is set the SDEI entry point and the rest of the kernel may be unmapped when we take an event. If this may be the case, use an entry trampoline that can switch to the kernel page tables. We can't use the provided PSTATE to determine whether to switch page tables as

[PATCH v5 15/16] arm64: mmu: add the entry tramolines start/end section markers into sections.h

SDEI needs to calculate an offset in the trampoline page too. Move the extern char[] to sections.h. This patch just moves code around. Signed-off-by: James Morse --- ... there were more of these in v2 of KPTI ... arch/arm64/include/asm/sections.h | 1 +

[PATCH v5 12/16] 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 v5 10/16] 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 v5 09/16] arm64: uaccess: Add PAN helper

Add __uaccess_{en,dis}able_hw_pan() helpers to set/clear the PSTATE.PAN bit. Signed-off-by: James Morse --- arch/arm64/include/asm/uaccess.h | 12 arch/arm64/kernel/suspend.c | 4 ++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git

[PATCH v5 13/16] arm64: acpi: Remove __init from acpi_psci_use_hvc() for use by SDEI

SDEI inherits the 'use hvc' bit that is also used by PSCI. PSCI does all its initialisation early, SDEI does its late. Remove the __init annotation from acpi_psci_use_hvc(). Signed-off-by: James Morse Acked-by: Catalin Marinas --- The function name

[PATCH v5 07/16] 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 firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add

[PATCH v5 11/16] 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 v5 14/16] firmware: arm_sdei: Discover SDEI support via ACPI

SDEI defines a new ACPI table to indicate the presence of the interface. The conduit is discovered in the same way as PSCI. For ACPI we need to create the platform device ourselves as SDEI doesn't have an entry in the DSDT. The SDEI platform device should be created after ACPI has been

[PATCH v5 01/16] 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. If the SDEI handler code runs behind KVMs back, it mustn't access

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

Make tpidr_el2 a cpu-offset for per-cpu variables in the same way the host uses tpidr_el1. This lets tpidr_el{1,2} have the same value, and on VHE they can be the same register. KVM calls hyp_panic() when anything unexpected happens. This may occur while a guest owns the EL1 registers. KVM

[PATCH v5 06/16] Docs: dt: 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, or from an IRQ that has been promoted to a firmware-assisted NMI. Add a new devicetree binding to describe

[PATCH v5 05/16] KVM: arm64: 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 v5 02/16] 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 v5 04/16] 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 v5 00/16] arm64/firmware: Software Delegated Exception Interface

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, but also supports vendor-defined events and binding IRQs as events. The document

Re: [PATCH] arm64: kvm: Prevent restoring stale PMSCR_EL1 for vcpu

On Wed, Dec 06, 2017 at 05:09:49PM +, Julien Thierry wrote: > When VHE is not present, KVM needs to save and restores PMSCR_EL1 when > possible. If SPE is used by the host, value of PMSCR_EL1 cannot be saved > for the guest. > If the host starts using SPE between two save+restore on the same

[PATCH] arm64: kvm: Prevent restoring stale PMSCR_EL1 for vcpu

When VHE is not present, KVM needs to save and restores PMSCR_EL1 when possible. If SPE is used by the host, value of PMSCR_EL1 cannot be saved for the guest. If the host starts using SPE between two save+restore on the same vcpu, restore will write the value of PMSCR_EL1 read during the first

[PATCH 3/3] arm64/sve: Avoid dereference of dead task_struct in KVM guest entry

When deciding whether to invalidate FPSIMD state cached in the cpu, the backend function sve_flush_cpu_state() attempts to dereference __this_cpu_read(fpsimd_last_state). However, this is not safe: there is no guarantee that this task_struct pointer is still valid, because the task could have

[PATCH 1/3] arm64: fpsimd: Prevent registers leaking from dead tasks

Currently, loading of a task's fpsimd state into the CPU registers is skipped if that task's state is already present in the registers of that CPU. However, the code relies on the struct fpsimd_state * (and by extension struct task_struct *) to unambiguously identify a task. There is a

[PATCH v2 0/3] arm64: SVE fixes for v4.15-rc2

This series contains a few fixes for known issues in the arm64 FPSIMD and SVE implementation. This supersedes the previous posting. [1] Note that although patch 2 is not a fix, it provides refactoring that is used by the fix in patch 3. [1] [PATCH 0/3] arm64: SVE fixes for v4.15-rc1

Re: [Intel-wired-lan] [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

On Sat, 2017-12-02 at 10:01 +0530, Sagar Arun Kamble wrote: > There is no real need for the users of timecounters to define > cyclecounter > and timecounter variables separately. Since timecounter will always > be > based on cyclecounter, have cyclecounter struct as member of > timecounter >

Re: [PATCH v6 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer

On Wed, Dec 06, 2017 at 05:17:28PM +0300, Yury Norov wrote: > On Wed, Dec 06, 2017 at 11:59:04AM +0100, Christoffer Dall wrote: > > On Tue, Dec 05, 2017 at 06:24:46PM +0300, Yury Norov wrote: > > > On Mon, Dec 04, 2017 at 09:05:05PM +0100, Christoffer Dall wrote: > > > > From: Christoffer Dall

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

On 06/12/17 15:18, Konrad Rzeszutek Wilk wrote: > On Wed, Dec 06, 2017 at 02:57:29PM +, Marc Zyngier wrote: >> On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote: >>> On Wed, Dec 06, 2017 at 02:38:25PM +, Marc Zyngier wrote: We're playing a dangerous game with struct alt_instr, as we

Re: [PATCH 10/37] KVM: arm64: Slightly improve debug save/restore functions

On 01/12/17 15:19, Christoffer Dall wrote: Hi Julien, On Tue, Nov 14, 2017 at 04:42:13PM +, Julien Thierry wrote: On 12/10/17 11:41, Christoffer Dall wrote: The debug save/restore functions can be improved by using the has_vhe() static key instead of the instruction alternative. Using

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

On Wed, Dec 06, 2017 at 02:57:29PM +, Marc Zyngier wrote: > On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote: > > On Wed, Dec 06, 2017 at 02:38:25PM +, Marc Zyngier wrote: > >> We're playing a dangerous game with struct alt_instr, as we produce > >> it using assembly tricks, but parse them

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

On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote: > On Wed, Dec 06, 2017 at 02:38:25PM +, 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

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

On Wed, Dec 06, 2017 at 02:38:25PM +, 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: 4.15-rc1 crash on Midway in teardown_hyp_mode()

On 06/12/17 14:17, Andre Przywara wrote: > Hi, > > On 06/12/17 14:11, Andre Przywara wrote: >> Hi, >> >> while trying to boot 4.15-rc1 on my Calxeda Midway I observed a crash >> (see below). I can't look further into this today, but wanted to report >> this anyway. >> >> Digging around a bit this

[PATCH 16/18] KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings

Both HYP io mappings call ioremap, followed by create_hyp_io_mappings. Let's move the ioremap call into create_hyp_io_mappings itself, which simplifies the code a bit and allows for further refactoring. Signed-off-by: Marc Zyngier --- arch/arm/include/asm/kvm_mmu.h | 3

[PATCH 17/18] KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state

As we're about to change the way we map devices at HYP, we need to move away from kern_hyp_va on an IO address. One way of achieving this is to store the VAs in kvm_vgic_global_state, and use that directly from the HYP code. This requires a small change to create_hyp_io_mappings so that it can

[PATCH 18/18] KVM: arm/arm64: Move HYP IO VAs to the "idmap" range

We so far mapped our HYP IO (which is essencially the GICv2 control registers) using the same method as for memory. It recently appeared that is a bit unsafe: we compute the HYP VA using the kern_hyp_va helper, but that helper is only designed to deal with kernel VAs coming from the linear map,

[PATCH 10/18] arm64; insn: Add encoder for the EXTR instruction

Add an encoder for the EXTR instruction, which also implements the ROR variant (where Rn == Rm). Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/insn.h | 6 ++ arch/arm64/kernel/insn.c | 32 2 files changed, 38

[PATCH 06/18] arm64: insn: Add N immediate encoding

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 --- arch/arm64/include/asm/insn.h | 1 + arch/arm64/kernel/insn.c | 4 2 files

[PATCH 11/18] arm64: insn: Allow ADD/SUB (immediate) with LSL #12

The encoder for ADD/SUB (immediate) can only cope with 12bit immediates, while there is an encoding for a 12bit immediate shifted by 12 bits to the left. Let's fix this small oversight by allowing the LSL_12 bit to be set. Signed-off-by: Marc Zyngier ---

[PATCH 14/18] KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state

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() becomes non-idempotent. On the other hand, there is no way that the

[PATCH 07/18] arm64: insn: Add encoder for bitwise operations using litterals

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 DecodeBitMasks(). Signed-off-by: Marc Zyngier ---

[PATCH 09/18] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag

Now that we can dynamically compute the kernek/hyp VA mask, there is need for a feature flag to trigger the alternative patching. Let's drop the flag and everything that depends on it. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/cpucaps.h | 2 +-

[PATCH 13/18] arm64: Update the KVM memory map documentation

Update the documentation to reflect the new tricks we play on the EL2 mappings... Signed-off-by: Marc Zyngier --- Documentation/arm64/memory.txt | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/arm64/memory.txt

[PATCH 15/18] KVM: arm/arm64: Demote HYP VA range display to being a debug feature

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 Zyngier --- virt/kvm/arm/mmu.c | 7 --- 1

[PATCH 12/18] arm64: KVM: Introduce EL2 VA randomisation

The main idea behind randomising the EL2 VA is that we usually have a few spare bits between the most significant bit of the VA mask and the most significant bit of the linear mapping. Those bits are by definition a bunch of zeroes, and could be useful to move things around a bit. Of course, the

[PATCH 08/18] arm64: KVM: Dynamically patch the kernel/hyp VA mask

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 to simplify that code by patching a single instruction with the correct mask

[PATCH 01/18] arm64: asm-offsets: Avoid clashing DMA definitions

asm-offsets.h contains a few DMA related definitions that have the exact same name than the enum members they are derived from. While this is not a problem so far, it will become an issue if both asm-offsets.h and include/linux/dma-direction.h: are pulled by the same file. Let's sidestep the

[PATCH 05/18] arm64: alternatives: Add dynamic patching feature

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. For a single feature, this is an all or nothing thing. It would be interesting to have a more fine grained way of patching the kernel though, where we

[PATCH 02/18] arm64: asm-offsets: Remove unused definitions

asm-offsets.h contains a number of definitions that are not used at all, and in some cases conflict with other definitions (such as NSEC_PER_SEC). Spring clean-up time. Signed-off-by: Marc Zyngier --- arch/arm64/kernel/asm-offsets.c | 5 - 1 file changed, 5

[PATCH 03/18] arm64: asm-offsets: Remove potential circular dependency

So far, we've been lucky enough that none of the include files that asm-offsets.c requires do include asm-offsets.h. This is about to change, and would introduce a nasty circular dependency... Let's now guard the inclusion of asm-offsets.h so that it never gets pulled from asm-offsets.c.

[PATCH 00/18] KVM/arm64: Randomise EL2 mappings

Whilst KVM benefits from the kernel randomisation when running VHE, there is no randomisation whatsoever when the kernel is running at EL1, as we directly use a fixed offset from the linear mapping. This series proposes to randomise the offset by inserting a few random bits between the MSB of the

[PATCH 04/18] arm64: alternatives: Enforce alignment of struct alt_instr

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 more fields to this structure, the alignment requirements of the structure

Re: 4.15-rc1 crash on Midway in teardown_hyp_mode()

On 06/12/17 14:11, Andre Przywara wrote: > Hi, > > while trying to boot 4.15-rc1 on my Calxeda Midway I observed a crash > (see below). I can't look further into this today, but wanted to report > this anyway. > > Digging around a bit this is due to the VGIC not initializing properly > due to

Re: 4.15-rc1 crash on Midway in teardown_hyp_mode()

Hi, On 06/12/17 14:11, Andre Przywara wrote: > Hi, > > while trying to boot 4.15-rc1 on my Calxeda Midway I observed a crash > (see below). I can't look further into this today, but wanted to report > this anyway. > > Digging around a bit this is due to the VGIC not initializing properly > due

Re: [PATCH v6 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer

On Wed, Dec 06, 2017 at 11:59:04AM +0100, Christoffer Dall wrote: > On Tue, Dec 05, 2017 at 06:24:46PM +0300, Yury Norov wrote: > > On Mon, Dec 04, 2017 at 09:05:05PM +0100, Christoffer Dall wrote: > > > From: Christoffer Dall > > > > > > The VGIC can now support the

4.15-rc1 crash on Midway in teardown_hyp_mode()

Hi, while trying to boot 4.15-rc1 on my Calxeda Midway I observed a crash (see below). I can't look further into this today, but wanted to report this anyway. Digging around a bit this is due to the VGIC not initializing properly due to GICC being advertised as just 4K, not 8K. This can be

Re: [PATCH 1/3] arm64: KVM: Move CPU ID reg trap setup off the world switch path

On Wed, Dec 06, 2017 at 11:53:00AM +0100, Christoffer Dall wrote: > On Tue, Dec 05, 2017 at 12:31:51PM +, Dave Martin wrote: > > On Tue, Dec 05, 2017 at 10:09:15AM +0100, Christoffer Dall wrote: > > > On Fri, Dec 01, 2017 at 03:19:40PM +, Dave Martin wrote: > > > > The HCR_EL2.TID3 flag

Re: [PATCH v6 7/8] KVM: arm/arm64: Provide a get_input_level for the arch timer

On Tue, Dec 05, 2017 at 06:24:46PM +0300, Yury Norov wrote: > On Mon, Dec 04, 2017 at 09:05:05PM +0100, Christoffer Dall wrote: > > From: Christoffer Dall > > > > The VGIC can now support the life-cycle of mapped level-triggered > > interrupts, and we no longer have

Re: [PATCH v6 2/8] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu

On Tue, Dec 05, 2017 at 04:46:08PM +0300, Yury Norov wrote: > On Mon, Dec 04, 2017 at 09:05:00PM +0100, Christoffer Dall wrote: > > From: Christoffer Dall > > > > We are about to distinguish between userspace accesses and mmio traps > > for a number of the mmio

Re: [PATCH 1/3] arm64: KVM: Move CPU ID reg trap setup off the world switch path

On Tue, Dec 05, 2017 at 12:31:51PM +, Dave Martin wrote: > On Tue, Dec 05, 2017 at 10:09:15AM +0100, Christoffer Dall wrote: > > On Fri, Dec 01, 2017 at 03:19:40PM +, Dave Martin wrote: > > > The HCR_EL2.TID3 flag needs to be set when trapping guest access to > > > the CPU ID registers is

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

On 2017/11/15 0:00, James Morse wrote: >> + * error has not been propagated >> + */ >> +run->exit_reason = KVM_EXIT_EXCEPTION; >> +run->ex.exception = ESR_ELx_EC_SERROR; >> +run->ex.error_code = KVM_SEI_SEV_RECOVERABLE; >> +

Re: [PATCH v6 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs

On 05/12/17 22:39, Yury Norov wrote: > On Tue, Dec 05, 2017 at 04:47:46PM +, Marc Zyngier wrote: >> On 05/12/17 15:03, Yury Norov wrote: >>> On Mon, Dec 04, 2017 at 09:05:04PM +0100, Christoffer Dall wrote: From: Christoffer Dall For mapped IRQs