BMC/Intel-BMC/linux.git/arch/arm/kernel/hyp-stub.S, branch dev-5.0

ARM: align .data section

2017-08-14T15:22:55+00:00

Robert Jarzmik reports that his PXA25x system fails to boot with 4.12, failing at __flush_whole_cache in arch/arm/mm/proc-xscale.S:215: 0xc0019e20 <+0>: ldr r1, [pc, #788] 0xc0019e24 <+4>: ldr r0, [r1] <== here with r1 containing 0xc06f82cd, which is the address of "clean_addr". Examination of the System.map shows: c06f22c8 D user_pmd_table c06f22cc d __warned.19178 c06f22cd d clean_addr indicating that a .data.unlikely section has appeared just before the .data section from proc-xscale.S. According to objdump -h, it appears that our assembly files default their .data alignment to 2**0, which is bad news if the preceding .data section size is not power-of-2 aligned at link time. Add the appropriate .align directives to all assembly files in arch/arm that are missing them where we require an appropriate alignment. Reported-by: Robert Jarzmik Tested-by: Robert Jarzmik Signed-off-by: Russell King

ARM: hyp-stub: Fix Thumb-2 compilation

2017-04-20T10:58:53+00:00

The assembler defaults to emiting the short form of ADR, leading to an out-of-range immediate. Using the wide version solves this issue. Fixes: bc845e4fbbbb ("ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code") Reported-by: Arnd Bergmann Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall

ARM: hyp-stub: Zero r0 on successful stub handling

2017-04-09T14:49:36+00:00

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 Signed-off-by: Christoffer Dall

ARM: hyp-stub/KVM: Kill __hyp_get_vectors

2017-04-09T14:49:34+00:00

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 Signed-off-by: Christoffer Dall

ARM: KVM: Implement HVC_RESET_VECTORS stub hypercall in the init code

2017-04-09T14:49:28+00:00

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 form of hypercall support. Tested-by: Keerthy Acked-by: Russell King Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall

ARM: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall

2017-04-09T14:49:27+00:00

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 Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall

ARM: hyp-stub: Define a return value for failed stub calls

2017-04-09T14:49:27+00:00

Define a standard return value to be returned when a hyp stub call fails. Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall

ARM: hyp-stub: Use r1 for the soft-restart address

2017-04-09T14:49:25+00:00

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 Signed-off-by: Christoffer Dall

ARM: KVM: Convert KVM to use HVC_GET_VECTORS

2017-04-09T14:49:24+00:00

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-by: Marc Zyngier Signed-off-by: Christoffer Dall

ARM: soft-reboot into same mode that we entered the kernel

2017-04-09T14:49:24+00:00

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. In order to do this, we need to pass a flag to cpu_reset() so it knows what to do, and we need to modify the kernel's own hypervisor stub to allow it to handle a soft-reboot. As we are always guaranteed to install our own hypervisor if we're entered in HYP32 mode, and KVM will have moved itself out of the way on kexec/normal reboot, we can assume that our hypervisor is in place when we want to kexec, so changing our hypervisor API should not be a problem. Tested-by: Keerthy Acked-by: Catalin Marinas Signed-off-by: Russell King Signed-off-by: Marc Zyngier Signed-off-by: Christoffer Dall