Thread (44 messages) 44 messages, 6 authors, 2017-03-21
STALE3417d

[PATCH v3 01/25] arm64: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall

From: james.morse@arm.com (James Morse)
Date: 2017-03-21 17:41:54
Also in: kvm, kvmarm

On 21/03/17 17:37, Marc Zyngier wrote:
On 21/03/17 17:25, James Morse wrote:
quoted
On 21/03/17 17:04, Catalin Marinas wrote:
quoted
On Mon, Mar 06, 2017 at 02:24:34PM +0000, Marc Zyngier wrote:
quoted
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.

Signed-off-by: Marc Zyngier <redacted>
---
 arch/arm64/include/asm/virt.h |  9 +++++++++
 arch/arm64/kernel/hyp-stub.S  | 13 ++++++++++++-
 2 files changed, 21 insertions(+), 1 deletion(-)
[...]
quoted
+ENTRY(__hyp_reset_vectors)
+	str	lr, [sp, #-16]!
+	mov	x0, #HVC_RESET_VECTORS
+	hvc	#0
+	ldr	lr, [sp], #16
+	ret
+ENDPROC(__hyp_reset_vectors)
Why do we need to specifically preserve lr across the hvc call? Is it
corrupted by the EL2 code (if yes, are other caller-saved registers that
need preserving)? I don't see something similar in the arch/arm code.
Kexec on arm64 needed a register to clobber in the hyp-stub's el1_sync code. We
wanted to preserve all the registers so soft_restart() could look more like a
function call.
I don't think we need this anymore. Once we enter __cpu_soft_restart(),
there is no turning back. Or am I missing something else?
My recollection of the history may be wrong: but we needed to mess with esr_el2
before we know its a soft_restart() call, at which point we didn't want to
clobber the registers. This was the strange use of x18 in kexec.


James
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help