[PATCH v5 25/34] ARM: KVM: Gracefully handle hyp-stubs being restored from under our feet

Should kvm_reboot() be invoked while guest is running, an IPI wil be issued, forcing the guest to exit and HYP being reset to the stubs. We will then try to reenter the guest, only to get an error (HVC_STUB_ERR). This patch allows this case to be gracefully handled by exiting the run loop.

[PATCH v5 30/34] ARM: hyp-stub/KVM: Kill __hyp_get_vectors

Nobody is using __hyp_get_vectors anymore, so let's remove both implementations (hyp-stub and KVM). Acked-by: Russell King Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier --- arch/arm/include/asm/virt.h | 10

[PATCH v5 31/34] arm64: hyp-stub/KVM: Kill __hyp_get_vectors

Nobody is using __hyp_get_vectors anymore, so let's remove both implementations (hyp-stub and KVM). Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/virt.h | 12 arch/arm64/kernel/hyp-stub.S | 13

[PATCH v5 33/34] ARM: hyp-stub: Zero r0 on successful stub handling

We now return HVC_STUB_ERR when a stub hypercall fails, but we leave whatever was in r0 on success. Zeroing it on return seems like a good idea. Signed-off-by: Marc Zyngier --- arch/arm/kernel/hyp-stub.S | 2 ++ arch/arm/kvm/init.S| 2 ++ 2 files changed, 4

[PATCH v5 32/34] arm64: hyp-stub: Zero x0 on successful stub handling

We now return HVC_STUB_ERR when a stub hypercall fails, but we leave whatever was in x0 on success. Zeroing it on return seems like a good idea. Signed-off-by: Marc Zyngier --- arch/arm64/kernel/hyp-stub.S | 4 +++- arch/arm64/kvm/hyp-init.S| 6 +++--- 2 files changed,

[PATCH v5 16/34] ARM: hyp-stub: Use r1 for the soft-restart address

It is not really obvious why the restart address should be in r3 when communicated to the hyp-stub. r1 should be perfectly adequate, and consistent with the rest of the code. Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas

[PATCH v5 22/34] ARM: KVM: Allow the main HYP code to use the init hyp stub implementation

We now have a full hyp-stub implementation in the KVM init code, but the main KVM code only supports HVC_GET_VECTORS, which is not enough. Instead of reinventing the wheel, let's reuse the init implementation by branching to the idmap page when called with a hyp-stub hypercall. Tested-by:

[PATCH v5 24/34] ARM: KVM: Implement HVC_SOFT_RESTART in the init code

Another missing stub hypercall is HVC_SOFT_RESTART. It turns out that it is pretty easy to implement in terms of HVC_RESET_VECTORS (since it needs to turn the MMU off). Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas

[PATCH v5 20/34] ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code

In order to restore HYP mode to its original condition, KVM currently implements __kvm_hyp_reset(). As we're moving towards a hyp-stub defined API, it becomes necessary to implement HVC_RESET_VECTORS. This patch adds the HVC_RESET_VECTORS hypercall to the KVM init code, which so far lacked any

[PATCH v5 13/34] ARM: soft-reboot into same mode that we entered the kernel

From: Russell King When we soft-reboot (eg, kexec) from one kernel into the next, we need to ensure that we enter the new kernel in the same processor mode as when we were entered, so that (eg) the new kernel can install its own hypervisor - the old kernel's

[PATCH v5 18/34] ARM: hyp-stub: Define a return value for failed stub calls

Define a standard return value to be returned when a hyp stub call fails. Signed-off-by: Marc Zyngier --- arch/arm/include/asm/virt.h | 2 ++ arch/arm/kernel/hyp-stub.S | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/virt.h

[PATCH v5 23/34] ARM: KVM: Convert __cpu_reset_hyp_mode to using __hyp_reset_vectors

We are now able to use the hyp stub to reset HYP mode. Time to kiss __kvm_hyp_reset goodbye, and use __hyp_reset_vectors. Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier

[PATCH v5 15/34] ARM: Update cpu_v7_reset documentation

cpu_v7_reset() now takes a second parameter indicating whether we should reboot in HYP or not. Update the documentation to reflect this. Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas Signed-off-by:

[PATCH v5 19/34] ARM: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall

Let's define a new stub hypercall that resets the HYP configuration to its default: hyp-stub vectors, and MMU disabled. Of course, for the hyp-stub itself, this is a trivial no-op. Hypervisors will have a bit more work to do. Tested-by: Keerthy Acked-by: Russell King

[PATCH v5 17/34] ARM: Expose the VA/IDMAP offset

The KVM code needs to be able to compute the address of symbols in its idmap page (the equivalent of a virt_to_idmap() call). Unfortunately, virt_to_idmap is slightly complicated, depending on the use of arch_phys_to_idmap_offset or not, and none of that is readily available at HYP. Instead,

[PATCH v5 21/34] ARM: KVM: Implement HVC_GET_VECTORS in the init code

Now that we have an infrastructure to handle hypercalls in the KVM init code, let's implement HVC_GET_VECTORS there. Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier

[PATCH v5 06/34] arm64: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall

Let's define a new stub hypercall that resets the HYP configuration to its default: hyp-stub vectors, and MMU disabled. Of course, for the hyp-stub itself, this is a trivial no-op. Hypervisors will have a bit more work to do. Acked-by: Catalin Marinas Reviewed-by: James

[PATCH v5 11/34] arm64: KVM: Implement HVC_SOFT_RESTART in the init code

Another missing stub hypercall is HVC_SOFT_RESTART. It turns out that it is pretty easy to implement in terms of HVC_RESET_VECTORS (since it needs to turn the MMU off). Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier ---

[PATCH v5 12/34] ARM: hyp-stub: improve ABI

From: Russell King Improve the hyp-stub ABI to allow it to do more than just get/set the vectors. We follow the example in ARM64, where r0 is used as an opcode with the other registers as an argument. Tested-by: Keerthy Acked-by: Catalin Marinas

[PATCH v5 10/34] arm64: KVM: Convert __cpu_reset_hyp_mode to using __hyp_reset_vectors

We are now able to use the hyp stub to reset HYP mode. Time to kiss __kvm_hyp_reset goodbye, and use __hyp_reset_vectors. Acked-by: Catalin Marinas Reviewed-by: James Morse Signed-off-by: Marc Zyngier ---

[PATCH v5 09/34] arm64: KVM: Allow the main HYP code to use the init hyp stub implementation

We now have a full hyp-stub implementation in the KVM init code, but the main KVM code only supports HVC_GET_VECTORS, which is not enough. Instead of reinventing the wheel, let's reuse the init implementation by branching to the idmap page when called with a hyp-stub hypercall. Acked-by: Catalin

[PATCH v5 07/34] arm64: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code

In order to restore HYP mode to its original condition, KVM currently implements __kvm_hyp_reset(). As we're moving towards a hyp-stub defined API, it becomes necessary to implement HVC_RESET_VECTORS. This patch adds the HVC_RESET_VECTORS hypercall to the KVM init code, which so far lacked any

[PATCH v5 01/34] arm64: hyp-stub: Stop pointlessly clobbering lr

When entering the kernel hyp stub, we check whether or not we've made it here through an HVC instruction, clobbering lr (aka x30) in the process. This is completely pointless, as HVC is the only way to get here (all traps to EL2 are disabled, no interrupt override is applied). So let's remove

[PATCH v5 08/34] arm64: KVM: Implement HVC_GET_VECTORS in the init code

Now that we have an infrastructure to handle hypercalls in the KVM init code, let's implement HVC_GET_VECTORS there. Acked-by: Catalin Marinas Reviewed-by: James Morse Signed-off-by: Marc Zyngier --- arch/arm64/kvm/hyp-init.S

[PATCH v5 00/34] arm/arm64: KVM: Rework the hyp-stub API

As noticed by RMK in this thread[1], the hyp-stub API on 32bit ARM could do with some TLC (it cannot perform a soft-restart at HYP, and has holes in the hyp-stub support in a number of places). In general, it would be desirable for the 32bit behaviour to align on 64bit, if only to ease

[PATCH v5 04/34] arm64: hyp-stub: Define a return value for failed stub calls

Define a standard return value to be returned when a hyp stub call fails, and make KVM use it for ARM_EXCEPTION_HYP_GONE (instead of using a KVM-specific value). Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/kvm_asm.h | 2 +- arch/arm64/include/asm/virt.h| 3

[PATCH v5 03/34] arm64: hyp-stub: Don't save lr in the EL1 code

The EL2 code is not corrupting lr anymore, so don't bother preserving it in the EL1 trampoline code. Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier --- arch/arm64/kernel/hyp-stub.S | 4 1 file changed, 4 deletions(-) diff --git

Re: [PATCH v4 19/28] ARM: KVM: Allow the main HYP code to use the init hyp stub implementation

On 03/04/17 18:32, Christoffer Dall wrote: > On Fri, Mar 24, 2017 at 03:01:23PM +, Marc Zyngier wrote: >> On 24/03/17 14:34, Christoffer Dall wrote: >>> On Tue, Mar 21, 2017 at 07:20:49PM +, Marc Zyngier wrote: We now have a full hyp-stub implementation in the KVM init code, but

Re: [PATCH v4 19/28] ARM: KVM: Allow the main HYP code to use the init hyp stub implementation

On Fri, Mar 24, 2017 at 03:01:23PM +, Marc Zyngier wrote: > On 24/03/17 14:34, Christoffer Dall wrote: > > On Tue, Mar 21, 2017 at 07:20:49PM +, Marc Zyngier wrote: > >> We now have a full hyp-stub implementation in the KVM init code, > >> but the main KVM code only supports

Re: [PATCH v4 07/28] arm64: KVM: Allow the main HYP code to use the init hyp stub implementation

On Fri, Mar 24, 2017 at 02:56:51PM +, Marc Zyngier wrote: > On 24/03/17 14:33, Christoffer Dall wrote: > > On Tue, Mar 21, 2017 at 07:20:37PM +, Marc Zyngier wrote: > >> We now have a full hyp-stub implementation in the KVM init code, > >> but the main KVM code only supports

[RFC 9/9] arm64: docs: document pointer authentication

Now that we've added code to support pointer authentication, add some documentation so that people can figure out if/how to use it. Since there are new enable bits in SCR_EL3 (and HCR_EL2), I think we should document something in booting.txt w.r.t. functionality advertised via ID registers being

[RFC 8/9] arm64/kvm: context-switch PAC registers

If we have pointer authentication support, a guest may wish to use it. This patch adds the infrastructure to allow it to do so. This is sufficient for basic testing, but not for real-world usage. A guest will still see pointer authentication support advertised in the ID registers, and we will

[RFC 6/9] arm64: add basic pointer authentication support

This patch adds basic support for pointer authentication, allowing userspace to make use of APIAKey. The kernel maintains an APIAKey value for each process (shared by all threads within), which is initialised to a random value at exec() time. Instructions using other keys (APIBKey, APDAKey,

[RFC 5/9] arm64: Don't trap host pointer auth use to EL2

To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and accesses to pointer authentication keys are not trapped to EL2 (where we will not be able to handle them). This patch ensures that HCR_EL2 is configured appropriately

[RFC 4/9] arm64/cpufeature: detect pointer authentication

So that we can dynamically handle the presence of pointer authentication functionality, wire up probing code in cpufeature.c. Currently, this only detects the presence of an architected algorithm. Signed-off-by: Mark Rutland Cc: Catalin Marinas

[RFC 1/9] asm-generic: mm_hooks: allow hooks to be overridden individually

Currently, an architecture must either implement all of the mm hooks itself, or use all of those provided by the asm-generic implementation. When an architecture only needs to override a single hook, it must copy the stub implementations from the asm-generic version. To avoid this repetition,

[RFC 2/9] arm64: add pointer authentication register bits

The ARMv8.3 pointer authentication extension adds: * New fields in ID_AA64ISAR1 to report the presence of pointer authentication functionality. * New control bits in SCTLR_ELx to enable this functionality. * New system registers to hold the keys necessary for this functionality. * A new

[RFC 3/9] arm64/cpufeature: add ARMv8.3 id_aa64isar1 bits

>From ARMv8.3 onwards, ID_AA64ISAR1 is no longer entirely RES0, and now has four fields describing the presence of pointer authentication functionality: * APA - address authentication present, using an architected algorithm * API - address authentication present, using an IMP DEF algorithm * GPA

[RFC 0/9] ARMv8.3 pointer authentication userspace support

This series adds support for the ARMv8.3 pointer authentication extension. I've included a quick intro to the extension below, with the usual series description below that. The final patch of the series adds additional documentation regarding the extension. I've based the series on the arm64

Re: [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

On Mon, Apr 03, 2017 at 03:22:11PM +0100, Mark Rutland wrote: > Hi, > > On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote: > > In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling > > unmap_stage2_range() on the entire memory range for the guest. This could > >

Re: [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

On 03/04/17 15:22, Mark Rutland wrote: Hi, On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote: In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire memory range for the guest. This could cause problems with other callers (e.g,

Re: [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

Hi, On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote: > In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling > unmap_stage2_range() on the entire memory range for the guest. This could > cause problems with other callers (e.g, munmap on a memslot) trying to >

[PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling unmap_stage2_range() on the entire memory range for the guest. This could cause problems with other callers (e.g, munmap on a memslot) trying to unmap a range. And since we have to unmap the entire Guest memory range holding a