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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9E642C25B74 for ; Tue, 21 May 2024 21:45:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MMmkRcX9Pefw68wDOFPU5K008mdlQUFveU/FcEuSPQ4=; b=UB8fBtcDTELSIM ZcnuRknoY1wgAx/owI1/LS1ZjIHvtm7WlibawTQce0TpUqjfqDgu77VqLmurhXIRK/HZpcipBXB41 AjotxWY6kdwPiqKt1xmfhoUPlsJ44T6iCNfOk6wimBsftLBia7l4AIpXUqeZxQFDb7e1AV3akkvFo Tle9+7zQHHB9WEiUq0Cr0dypZ1JrTSgS9WB/CtX4wTMB199yivpmjCYHrS8wHXTxpH32WmAD/vJAp 2dkGFUN7gq77Qgujrt7Gg0PBEMUX+e0CqocCIgKqoYnIFvb3220XSNL6kEG+1PD0ItlgGZD2lPwo3 eB/jBTIlB4RvC5gbl4wQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9XI5-00000001Bo4-3rCD; Tue, 21 May 2024 21:45:01 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9XI2-00000001BnU-3syj for linux-arm-kernel@lists.infradead.org; Tue, 21 May 2024 21:45:00 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 84A26CE10AF; Tue, 21 May 2024 21:44:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB3E7C2BD11; Tue, 21 May 2024 21:44:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716327895; bh=OslvGJTX1H4fr1dtw3BAyK2V8BlFIR6fSAE2gHca+2s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hHv0CZUpF+70N7ar7q+AurG+s9p3Kf/qlhAylMEcfTOCSm0oSJxiuzbnTmq392pjI s8yzEKoYYiV4UG0d+7Jpi0YzXpW82oYFQr6BgkjVn81pjYPpqNJm2vRESvEp0gID60 fiXOCrUcR3QNZv2XiOe6mKZUIxp2Lrrc+6ZxAXdBpDjmOf/iyCR8Pg+LGnP0sr2RNP PZQg6dDImPXAeCFMlthZ7IwS6lURaxTtVJ3rsVo91OqCCrgjhRA+qYq/rmR9pRbTDf 5AX0Panve60MLxhExu6D2HT6SgxRZAFJNJmg22M6oJviLjnb+Na8/ofp2koqhi0Z+J QWrur09DSdAJw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1s9XHx-00EoGs-4M; Tue, 21 May 2024 22:44:53 +0100 Date: Tue, 21 May 2024 22:44:52 +0100 Message-ID: <86plten8kr.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.com Subject: Re: [PATCH v2 5/7] KVM: arm64: Allocate memory at hyp for host sve state in pKVM In-Reply-To: <20240521163720.3812851-6-tabba@google.com> References: <20240521163720.3812851-1-tabba@google.com> <20240521163720.3812851-6-tabba@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, qperret@google.com, seanjc@google.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com, rananta@google.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240521_144459_353205_EEDA5515 X-CRM114-Status: GOOD ( 37.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Tue, 21 May 2024 17:37:18 +0100, Fuad Tabba wrote: > > Protected mode needs to maintain (save/restore) the host's sve > state, rather than relying on the host kernel to do that. This is > to avoid leaking information to the host about guests and the > type of operations they are performing. > > As a first step towards that, allocate memory at hyp, per cpu, to > hold the host sve data. The following patch will use this memory > to save/restore the host state. What I read in the code contradicts this statement. The memory is definitely allocated on the *host*. > > Signed-off-by: Fuad Tabba > --- > Note that the last patch in this series will consolidate the > setup of the host's fpsimd and sve states, which currently take > place in two different locations. Moreover, that last patch will > also place the host fpsimd and sve_state pointers in a union. > --- > arch/arm64/include/asm/kvm_host.h | 2 + > arch/arm64/include/asm/kvm_pkvm.h | 9 ++++ > arch/arm64/include/uapi/asm/ptrace.h | 14 ++++++ > arch/arm64/kvm/arm.c | 68 ++++++++++++++++++++++++++++ > arch/arm64/kvm/hyp/nvhe/setup.c | 24 ++++++++++ > 5 files changed, 117 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 0a5fceb20f3a..7b3745ef1d73 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -535,7 +535,9 @@ struct kvm_cpu_context { > */ > struct kvm_host_data { > struct kvm_cpu_context host_ctxt; > + > struct user_fpsimd_state *fpsimd_state; /* hyp VA */ > + struct user_sve_state *sve_state; /* hyp VA */ > > /* Ownership of the FP regs */ > enum { > diff --git a/arch/arm64/include/asm/kvm_pkvm.h b/arch/arm64/include/asm/kvm_pkvm.h > index ad9cfb5c1ff4..b9d12e123efb 100644 > --- a/arch/arm64/include/asm/kvm_pkvm.h > +++ b/arch/arm64/include/asm/kvm_pkvm.h > @@ -128,4 +128,13 @@ static inline unsigned long hyp_ffa_proxy_pages(void) > return (2 * KVM_FFA_MBOX_NR_PAGES) + DIV_ROUND_UP(desc_max, PAGE_SIZE); > } > > +static inline size_t pkvm_host_sve_state_size(void) > +{ > + if (!system_supports_sve()) > + return 0; > + > + return size_add(sizeof(struct user_sve_state), > + SVE_SIG_REGS_SIZE(sve_vq_from_vl(kvm_host_sve_max_vl))); > +} > + > #endif /* __ARM64_KVM_PKVM_H__ */ > diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h > index 7fa2f7036aa7..77aabf964071 100644 > --- a/arch/arm64/include/uapi/asm/ptrace.h > +++ b/arch/arm64/include/uapi/asm/ptrace.h > @@ -120,6 +120,20 @@ struct user_sve_header { > __u16 __reserved; > }; > > +struct user_sve_state { > + __u64 zcr_el1; > + > + /* > + * Ordering is important since __sve_save_state/__sve_restore_state > + * relies on it. > + */ > + __u32 fpsr; > + __u32 fpcr; > + > + /* Must be SVE_VQ_BYTES (128 bit) aligned. */ > + __u8 sve_regs[]; > +}; > + Huh, why is this in uapi? Why should userspace even care about this at all? From what I can tell, this is purely internal to the kernel, and in any case, KVM isn't tied to that format if it doesn't dump stuff in the userspace thread context. Given the number of bugs this format has generated, I really wouldn't mind moving away from it. > /* Definitions for user_sve_header.flags: */ > #define SVE_PT_REGS_MASK (1 << 0) > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 9e565ea3d645..a9b1b0e9c319 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -1931,6 +1931,11 @@ static unsigned long nvhe_percpu_order(void) > return size ? get_order(size) : 0; > } > > +static size_t pkvm_host_sve_state_order(void) > +{ > + return get_order(pkvm_host_sve_state_size()); > +} > + > /* A lookup table holding the hypervisor VA for each vector slot */ > static void *hyp_spectre_vector_selector[BP_HARDEN_EL2_SLOTS]; > > @@ -2316,7 +2321,15 @@ static void __init teardown_hyp_mode(void) > for_each_possible_cpu(cpu) { > free_page(per_cpu(kvm_arm_hyp_stack_page, cpu)); > free_pages(kvm_nvhe_sym(kvm_arm_hyp_percpu_base)[cpu], nvhe_percpu_order()); > + > + if (system_supports_sve() && is_protected_kvm_enabled()) { > + struct user_sve_state *sve_state; > + > + sve_state = per_cpu_ptr_nvhe_sym(kvm_host_data, cpu)->sve_state; > + free_pages((unsigned long) sve_state, pkvm_host_sve_state_order()); > + } > } > + > } > > static int __init do_pkvm_init(u32 hyp_va_bits) > @@ -2399,6 +2412,50 @@ static int __init kvm_hyp_init_protection(u32 hyp_va_bits) > return 0; > } > > +static int init_pkvm_host_sve_state(void) > +{ > + int cpu; > + > + if (!system_supports_sve()) > + return 0; > + > + /* Allocate pages for host sve state in protected mode. */ > + for_each_possible_cpu(cpu) { > + struct page *page = alloc_pages(GFP_KERNEL, pkvm_host_sve_state_order()); > + See? That's definitely not a HYP allocation. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel