[kvmarm:master 1/3] arch/arm/kvm/mmu.c:302:14: error: 'S2_PUD_SIZE' undeclared

tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git master head: 1f1c45c6f66a586ca420ca02cbd93a35690394f9 commit: f9d9eb7f7a2c7e388861fe1cdb253f63e63555fe [1/3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd config: arm-axm55xx_defconfig (attached as .config) compiler:

[PATCH v5 34/34] arm/arm64: Add hyp-stub API documentation

In order to help people understanding the hyp-stub API that exists between the host kernel and the hypervisor mode (whether a hypervisor has been installed or not), let's document said API. As with any form of documentation, I expect it to become obsolete and completely misleading within 20 minute

[PATCH v5 29/34] ARM: decompressor: Remove __hyp_get_vectors usage

When the compressed image needs to be relocated to avoid being overwritten by the decompression process, we need to relocate the hyp vectors as well so that we can find them once the decompression has taken effect. For that, we perform the following calculation: u32 v = __hyp_get_vectors()

[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. Signed

[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 -- arch/arm/kernel/hyp-stub.S | 13 + arch/arm/kvm/init.S

[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 + arch/arm64/kvm/hyp-init.S | 7 +--

[PATCH v5 27/34] arm/arm64: KVM: Remove kvm_get_idmap_start

With __cpu_reset_hyp_mode having become fairly dumb, there is no need for kvm_get_idmap_start anymore. Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier --- arch/arm/include/asm/kvm_mmu.h | 1 - arch/arm/kvm/mmu.c | 5 - arch/arm64/include/asm/kvm_mmu.h | 1 - 3 files ch

[PATCH v5 14/34] ARM: KVM: Convert KVM to use HVC_GET_VECTORS

The conversion of the HYP stub ABI to something similar to arm64 left the KVM code broken, as it doesn't know about the new stub numbering. Let's move the various #defines to virt.h, and let KVM use HVC_GET_VECTORS. Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas Signed-off-

[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 insertions(+) diff --git a/ar

[PATCH v5 28/34] arm/arm64: KVM: Use HVC_RESET_VECTORS to reinit HYP mode

Instead of trying to compare the value given by __hyp_get_vectors(), which doesn't offer any real guarantee to be the stub's address, use HVC_RESET_VECTORS to make sure we're in a sane state to reinstall KVM across PM events. Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier --- arch/arm/kv

[PATCH v5 26/34] arm/arm64: KVM: Use __hyp_reset_vectors() directly

__cpu_reset_hyp_mode doesn't need to be passed any argument now, as the hyp-stub implementations are self-contained, and is now reduced to just calling __hyp_reset_vectors(). Let's drop the wrapper and use the stub hypercall directly. Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier --- ar

[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, 6 insertions(+), 4 del

[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 Signed-off-by: Marc Zyngier --- arch/arm/kernel/hy

[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: Keerthy

[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 Signed-off-by: Marc Zyngier --- arch/arm/kvm/init.S | 14

[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 --- arch/arm/include/asm/kvm_asm.h | 2 -- arch/arm/include/asm/kvm_host.h

[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: Marc Zyngier --- arch/arm/mm/proc-v7.S | 3 ++- 1 file changed, 2 inserti

[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 hypervisor will have been overwritten.

[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 b/arch/arm/include/asm/virt.

[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 for

[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 Acked-by: Catalin Marinas

[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, expos

[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 --- arch/arm/kvm/init.S | 7 ++- 1 file changed, 6 insertions(+), 1 deletion

[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 Morse Signed-off-by: Mar

[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 --- arch/arm64/kvm/hyp-init.S | 31 +++ 1 fi

[PATCH v5 02/34] arm64: KVM: Move lr save/restore to do_el2_call

At the moment, we only save/restore lr if on VHE, as we rely only the EL1 code to have preserved it in the non-VHE case. As we're about to get rid of the latter, let's move the save/restore code to the do_el2_call macro, unifying both code paths. Acked-by: Catalin Marinas Signed-off-by: Marc Zyn

[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 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 Signed-off-by: Russell King Signed-off-by: Mar

[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 --- arch/arm64/include/asm/kvm_asm.h | 1 - arch/arm64/include/asm/kvm_host.h | 3 +-- arc

[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 for

[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 thi

[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 | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --

[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 maintenance.

[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 +++ arch/arm64/kernel/h

[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 a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp

[PATCH v5 05/34] arm64: hyp-stub: Update documentation in asm/virt.h

Comments in asm/virt.h are slightly out of date, so let's align them with the new behaviour of the code. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/virt.h | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/includ

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 t

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 HVC_GET_VECTORS

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 HVC_GET_VECTORS

Re: [PATCH v2 0/9] KVM: arm/arm64: race fixes and vcpu requests

On 03/04/2017 17:28, Christoffer Dall wrote: >> - No longer based on Radim's vcpu request API rework[1], except for >> including "add kvm_request_pending" as patch 1/9 [drew] > > I lost track here; did those patches get merged or dropped and why are > we not basing this work on them anymor

Re: [PATCH v2 0/9] KVM: arm/arm64: race fixes and vcpu requests

Hi Drew, On Fri, Mar 31, 2017 at 06:06:49PM +0200, Andrew Jones wrote: > This series fixes some hard to produce races by introducing the use of > vcpu requests. It also fixes a couple easier to produce races, ones > that have been produced with the PSCI kvm-unit-test test. The easy two > are add

[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 a

[RFC 7/9] arm64: expose PAC bit positions via ptrace

When pointer authentication is in use, data/instruction pointers have a number of PAC bits inserted into them. The number and position of these bits depends on the configured TCR_ELx.TxSZ and whether tagging is enabled. ARMv8.3 allows tagging to differ for instruction and data pointers. For usersp

[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 need

[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, APDBKe

[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 Cc: Suzuki K Poulose Cc: Will Deacon --- arch/a

[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, allo

[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 ESR

[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 for-

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 > > cau

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, m

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 > unma

[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 s