From patchwork Tue Mar 21 18:36:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 9637343 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 990C2601E9 for ; Tue, 21 Mar 2017 18:38:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8E4D527B13 for ; Tue, 21 Mar 2017 18:38:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 82FE42830A; Tue, 21 Mar 2017 18:38:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C210627B13 for ; Tue, 21 Mar 2017 18:38:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757710AbdCUShs (ORCPT ); Tue, 21 Mar 2017 14:37:48 -0400 Received: from foss.arm.com ([217.140.101.70]:58200 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757413AbdCUSgz (ORCPT ); Tue, 21 Mar 2017 14:36:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F076D2B; Tue, 21 Mar 2017 11:36:53 -0700 (PDT) Received: from [10.1.207.16] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A8C7E3F2E5; Tue, 21 Mar 2017 11:36:52 -0700 (PDT) Subject: Re: [PATCH v3 01/25] arm64: hyp-stub: Implement HVC_RESET_VECTORS stub hypercall To: James Morse References: <20170306142458.8875-1-marc.zyngier@arm.com> <20170306142458.8875-2-marc.zyngier@arm.com> <20170321170407.GD21829@e104818-lin.cambridge.arm.com> <58D1620E.30001@arm.com> <0cce34c1-cb6f-0ba3-ac98-c0a0e986dc86@arm.com> <58D165E2.7050501@arm.com> Cc: Catalin Marinas , Russell King , Ard Biesheuvel , cdall@linaro.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu From: Marc Zyngier Organization: ARM Ltd Message-ID: <8b0b5948-368f-530c-cd64-7b97dbe2312a@arm.com> Date: Tue, 21 Mar 2017 18:36:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <58D165E2.7050501@arm.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 21/03/17 17:41, James Morse wrote: > On 21/03/17 17:37, Marc Zyngier wrote: >> On 21/03/17 17:25, James Morse wrote: >>> On 21/03/17 17:04, Catalin Marinas wrote: >>>> On Mon, Mar 06, 2017 at 02:24:34PM +0000, Marc Zyngier wrote: >>>>> 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 >>>>> --- >>>>> arch/arm64/include/asm/virt.h | 9 +++++++++ >>>>> arch/arm64/kernel/hyp-stub.S | 13 ++++++++++++- >>>>> 2 files changed, 21 insertions(+), 1 deletion(-) >>>> [...] >>>>> +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. After a bit of digging together with James, we found the guilty one. The hyp-stub entry code uses lr (aka x30) as a scratch register to find out if we've made it here via a HVC instruction. This is an absolutely pointless test, because by definition HVC is the only way to get there. I've ended up with the following patch: I'll split that in convenient patches and repost the series. Thanks, M. diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index 8ccdd549f7c7..210bd6b3849d 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -55,12 +55,6 @@ ENDPROC(__hyp_stub_vectors) .align 11 el1_sync: - mrs x30, esr_el2 - lsr x30, x30, #ESR_ELx_EC_SHIFT - - cmp x30, #ESR_ELx_EC_HVC64 - b.ne 9f // Not an HVC trap - cmp x0, #HVC_SET_VECTORS b.ne 2f msr vbar_el2, x1 @@ -120,18 +114,14 @@ ENDPROC(\label) */ ENTRY(__hyp_set_vectors) - str lr, [sp, #-16]! mov x1, x0 mov x0, #HVC_SET_VECTORS hvc #0 - ldr lr, [sp], #16 ret ENDPROC(__hyp_set_vectors) ENTRY(__hyp_reset_vectors) - str lr, [sp, #-16]! mov x0, #HVC_RESET_VECTORS hvc #0 - ldr lr, [sp], #16 ret ENDPROC(__hyp_reset_vectors) diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S index 1277f81b63b7..5170ce1021da 100644 --- a/arch/arm64/kvm/hyp/hyp-entry.S +++ b/arch/arm64/kvm/hyp/hyp-entry.S @@ -32,17 +32,17 @@ * Shuffle the parameters before calling the function * pointed to in x0. Assumes parameters in x[1,2,3]. */ + str lr, [sp, #-16]! mov lr, x0 mov x0, x1 mov x1, x2 mov x2, x3 blr lr + ldr lr, [sp], #16 .endm ENTRY(__vhe_hyp_call) - str lr, [sp, #-16]! do_el2_call - ldr lr, [sp], #16 /* * We used to rely on having an exception return to get * an implicit isb. In the E2H case, we don't have it anymore.