From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23C1DC433E2 for ; Tue, 8 Sep 2020 10:54:29 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CD25E2087C for ; Tue, 8 Sep 2020 10:54:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ArNwLPnZ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="nT2RetXC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CD25E2087C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bfHvhc32pKayd60WO87kXlo8c3ttHdvagNBH/6cDMLo=; b=ArNwLPnZrFeb2xHsapExMz4sk L8M2502xgBZxABJVrXVRHb4yOle9oBacKDFrtBmOR7dPBKuHdxnpJlyeF0+l7ZQdGDsmVb7HUUvO1 J7mmMYVya3LGdsyeNME/90C0H4lEvxHb6E20+nskZ8LG71hYmMfGNjqL0hoyZVgiuYUFam23lAk8D hwN4xwDznUHn87JW7MvLpPnCwTLOsYr05BfayAnYc6r4cFYtVzVapku88xYZySKNeCpCZwrw2PmYR 6EouB9LEbtV+pc3UjAkK27pIQpOWLWBf8LukNjOWjQhnBCrK9g/R2aid2O0ZWXTa+0F+uhN0OBZ/D RueQEK48Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFbFI-0007cl-6V; Tue, 08 Sep 2020 10:53:04 +0000 Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFbFC-0007at-AN for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 10:53:01 +0000 Received: by mail-wr1-x441.google.com with SMTP id e16so18616639wrm.2 for ; Tue, 08 Sep 2020 03:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=F9dk15GOlkPaspc7wMO0W0WDOaJSPahbZyg1od4IkXE=; b=nT2RetXCMCIHxCozmm0YXIPz+w4wnOIpdQ1LaHRgbtS5jRkubzkf/h1pBJYQZQC2Ed iLHCzacsvGAOYc13pL9GiaWJPmcit1vNIfMoaEKF/0vhWNx8TTnpB6LSoR+P1kVxW83w IbgvwTLcIvUF5DiUIfcPnZhtesH0DHTx0kc88ss7v0EI626y7EsaT+EM66E0ttZ5gADb VS37kAClXrTa1eWYfHHf5yoCihw5+ZiwZ53J/bx8/z+U1ORJMyag9ilkNstjQpOZhGRu zuu86z73dazgXe+o1iGUm3QU1dgv53bhYhChn6Q1w4uq7sn0GpoGpaqKdFpcNq38rf5b 53mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=F9dk15GOlkPaspc7wMO0W0WDOaJSPahbZyg1od4IkXE=; b=MpTuKZbgmbQhJJy5qpZ/lMJLzNZEgt+kshGG9lofd7c5hIvbBSipcYmRKPZPEyKvCC d8AZ3EmkiooT4WecknDrxKegk4T4h9/OxSsAP6jPPGbPUQndrD2XGxJmtyU2ED2yFgx8 bezgRBVnpQag64zNenz32AnsMwhwVcgdIFPxFayPD+ZzSnokujtdEiJs9hg7wze0hYG4 3bSA0XmJU439S6fGsvzGJMSgMzIMQiVIDQ1QrotM5a3yUU7ysDY3TKkoeNGlevEBeLls CVEJ2gNFrG329xXQmajZGprcoky5OFxM1a8fOdPcXol6cHipbb/0bYGP0uRLcamcgMwC 7syg== X-Gm-Message-State: AOAM530PF0OXnWbPwB7gelpMmS0ivrXj1/joR6GaQ9EqS68/3rgY3G5+ EaBeSMG56Ra7vEqjzuB6KateMA== X-Google-Smtp-Source: ABdhPJzKC0xIce/ZJE7/ALHltWwu0Ivsi9UsMCddFNSDQTSB9CZWQTxkRe5v4Ji2rFyULc8qaZ0P/A== X-Received: by 2002:a5d:568d:: with SMTP id f13mr25650988wrv.303.1599562376964; Tue, 08 Sep 2020 03:52:56 -0700 (PDT) Received: from google.com ([2a00:79e0:d:109:4a0f:cfff:fe4a:6363]) by smtp.gmail.com with ESMTPSA id s5sm33668521wrm.33.2020.09.08.03.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 03:52:56 -0700 (PDT) Date: Tue, 8 Sep 2020 11:52:51 +0100 From: Andrew Scull To: Marc Zyngier Subject: Re: [PATCH v3 08/18] KVM: arm64: Introduce hyp context Message-ID: <20200908105251.GD3268721@google.com> References: <20200903135307.251331-1-ascull@google.com> <20200903135307.251331-9-ascull@google.com> <87sgbtlnq0.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87sgbtlnq0.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_065258_518751_C8900FCC X-CRM114-Status: GOOD ( 25.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kernel-team@android.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, Sudeep Holla , will@kernel.org, kvmarm@lists.cs.columbia.edu, julien.thierry.kdev@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Sep 07, 2020 at 02:29:11PM +0100, Marc Zyngier wrote: > On Thu, 03 Sep 2020 14:52:57 +0100, > Andrew Scull wrote: > > > > During __guest_enter, save and restore from a new hyp context rather > > than the host context. This is preparation for separation of the hyp and > > host context in nVHE. > > > > Signed-off-by: Andrew Scull > > --- > > arch/arm64/include/asm/kvm_hyp.h | 3 ++- > > arch/arm64/kernel/image-vars.h | 1 + > > arch/arm64/kvm/arm.c | 10 ++++++++++ > > arch/arm64/kvm/hyp/entry.S | 10 +++++----- > > arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +- > > arch/arm64/kvm/hyp/nvhe/switch.c | 2 +- > > arch/arm64/kvm/hyp/vhe/switch.c | 2 +- > > 7 files changed, 21 insertions(+), 9 deletions(-) > > > > diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h > > index 1e2491da324e..0b525e05e5bf 100644 > > --- a/arch/arm64/include/asm/kvm_hyp.h > > +++ b/arch/arm64/include/asm/kvm_hyp.h > > @@ -12,6 +12,7 @@ > > #include > > #include > > > > +DECLARE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt); > > DECLARE_PER_CPU(unsigned long, kvm_hyp_vector); > > > > #define read_sysreg_elx(r,nvh,vh) \ > > @@ -89,7 +90,7 @@ void activate_traps_vhe_load(struct kvm_vcpu *vcpu); > > void deactivate_traps_vhe_put(void); > > #endif > > > > -u64 __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host_ctxt); > > +u64 __guest_enter(struct kvm_vcpu *vcpu); > > > > void __noreturn hyp_panic(void); > > #ifdef __KVM_NVHE_HYPERVISOR__ > > diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h > > index 54bb0eb34b0f..9f419e4fc66b 100644 > > --- a/arch/arm64/kernel/image-vars.h > > +++ b/arch/arm64/kernel/image-vars.h > > @@ -71,6 +71,7 @@ KVM_NVHE_ALIAS(kvm_update_va_mask); > > /* Global kernel state accessed by nVHE hyp code. */ > > KVM_NVHE_ALIAS(arm64_ssbd_callback_required); > > KVM_NVHE_ALIAS(kvm_host_data); > > +KVM_NVHE_ALIAS(kvm_hyp_ctxt); > > KVM_NVHE_ALIAS(kvm_hyp_vector); > > KVM_NVHE_ALIAS(kvm_vgic_global_state); > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > index b6442c6be5ad..ae4b34f91e94 100644 > > --- a/arch/arm64/kvm/arm.c > > +++ b/arch/arm64/kvm/arm.c > > @@ -47,6 +47,7 @@ __asm__(".arch_extension virt"); > > #endif > > > > DEFINE_PER_CPU(struct kvm_host_data, kvm_host_data); > > +DEFINE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt); > > [back to this patch after having reviewed a few of the subsequent > ones] > > Given the variety of contexts you are introducing, I wonder if the > best course of action for most of this isn't simply to use the EL2 > stack rather than defining ad-hoc structures. > > The host save/restore you are introducing in a later patch certainly > could do without a separate data structure (hello, struct pt_regs) and > the hyp/host churn. > > What do you think? We could define the start of the stack to be the host context (IIRC, TF-A does something along those lines). Maybe there is some locality benefit? The percpu definitions become less onerous in code with David's percpu series as the mapping to EL2 is done in bulk rather than per item. Ptrauth switching is something that doesn't fall under pt_regs (it's no longer in this series, but will need to be switched later on). I had chosen to reuse the existing structs but a host-specilized context might be preferred? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel