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=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 CEE77C433DB for ; Mon, 22 Mar 2021 13:46:50 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 503246198C for ; Mon, 22 Mar 2021 13:46:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 503246198C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=desiato.20200630; 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=N1RqBXMjsfreMjfvqP5rFQJIgSBCtVEo92fmCRRqjvs=; b=rJUUevM0rfn/smBJ6SNw9xip9 4bvxq6AM1p4of/CZvHNvlQAaJvw7vGWcRft6rNeqMsw+UlZJyA64oq8RUi6Clm8EDYa3aoXIZQe+p uLjtrE43IPT+nIWWxB8jsKAe3XjR11R9bPQHa/U6w5q2Fn4iftrlplWuWCd0ia6V6Hb/zuY4STq0R E6SfQNIzMc2qAuEdTJRERzaQR7tuFyFgTRywXMmvrFDgq/wNbBuOwTH5Wm0Bc9yV2arBnTEWKI60Y 80YgMnMYXO7ouquKU7G1MTIFivQiwsCF3g33a4YmztSPEYk0BJ0/k07Yxj37T5kjA+ogWn/aHRGON VguhHsr6w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lOKrV-00BjTX-M0; Mon, 22 Mar 2021 13:44:53 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lOKrQ-00BjSX-3z for linux-arm-kernel@lists.infradead.org; Mon, 22 Mar 2021 13:44:50 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AE81F61923; Mon, 22 Mar 2021 13:44:41 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lOKrH-0034qY-O6; Mon, 22 Mar 2021 13:44:39 +0000 Date: Mon, 22 Mar 2021 13:44:38 +0000 Message-ID: <87o8fbgv5l.wl-maz@kernel.org> From: Marc Zyngier To: Quentin Perret Cc: catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, android-kvm@google.com, seanjc@google.com, mate.toth-pal@arm.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, tabba@google.com, ardb@kernel.org, mark.rutland@arm.com, dbrazdil@google.com Subject: Re: [PATCH v6 13/38] KVM: arm64: Enable access to sanitized CPU features at EL2 In-Reply-To: <20210319100146.1149909-14-qperret@google.com> References: <20210319100146.1149909-1-qperret@google.com> <20210319100146.1149909-14-qperret@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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: qperret@google.com, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, android-kvm@google.com, seanjc@google.com, mate.toth-pal@arm.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, kernel-team@android.com, kvmarm@lists.cs.columbia.edu, tabba@google.com, ardb@kernel.org, mark.rutland@arm.com, dbrazdil@google.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-20210322_134448_589007_6070B836 X-CRM114-Status: GOOD ( 36.44 ) 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 Hi Quentin, On Fri, 19 Mar 2021 10:01:21 +0000, Quentin Perret wrote: > > Introduce the infrastructure in KVM enabling to copy CPU feature > registers into EL2-owned data-structures, to allow reading sanitised > values directly at EL2 in nVHE. > > Given that only a subset of these features are being read by the > hypervisor, the ones that need to be copied are to be listed under > together with the name of the nVHE variable that > will hold the copy. This introduces only the infrastructure enabling > this copy. The first users will follow shortly. > > Signed-off-by: Quentin Perret > --- > arch/arm64/include/asm/cpufeature.h | 1 + > arch/arm64/include/asm/kvm_cpufeature.h | 22 ++++++++++++++++++++++ > arch/arm64/include/asm/kvm_host.h | 4 ++++ > arch/arm64/kernel/cpufeature.c | 13 +++++++++++++ > arch/arm64/kvm/sys_regs.c | 19 +++++++++++++++++++ > 5 files changed, 59 insertions(+) > create mode 100644 arch/arm64/include/asm/kvm_cpufeature.h > > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h > index 61177bac49fa..a85cea2cac57 100644 > --- a/arch/arm64/include/asm/cpufeature.h > +++ b/arch/arm64/include/asm/cpufeature.h > @@ -607,6 +607,7 @@ void check_local_cpu_capabilities(void); > > u64 read_sanitised_ftr_reg(u32 id); > u64 __read_sysreg_by_encoding(u32 sys_id); > +int copy_ftr_reg(u32 id, struct arm64_ftr_reg *dst); > > static inline bool cpu_supports_mixed_endian_el0(void) > { > diff --git a/arch/arm64/include/asm/kvm_cpufeature.h b/arch/arm64/include/asm/kvm_cpufeature.h > new file mode 100644 > index 000000000000..3d245f96a9fe > --- /dev/null > +++ b/arch/arm64/include/asm/kvm_cpufeature.h > @@ -0,0 +1,22 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (C) 2020 - Google LLC > + * Author: Quentin Perret > + */ > + > +#ifndef __ARM64_KVM_CPUFEATURE_H__ > +#define __ARM64_KVM_CPUFEATURE_H__ > + > +#include > + > +#include > + > +#if defined(__KVM_NVHE_HYPERVISOR__) > +#define DECLARE_KVM_HYP_CPU_FTR_REG(name) extern struct arm64_ftr_reg name > +#define DEFINE_KVM_HYP_CPU_FTR_REG(name) struct arm64_ftr_reg name > +#else > +#define DECLARE_KVM_HYP_CPU_FTR_REG(name) extern struct arm64_ftr_reg kvm_nvhe_sym(name) > +#define DEFINE_KVM_HYP_CPU_FTR_REG(name) BUILD_BUG() > +#endif > + > +#endif > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 6a2031af9562..02e172dc5087 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -740,9 +740,13 @@ void kvm_clr_pmu_events(u32 clr); > > void kvm_vcpu_pmu_restore_guest(struct kvm_vcpu *vcpu); > void kvm_vcpu_pmu_restore_host(struct kvm_vcpu *vcpu); > + > +void setup_kvm_el2_caps(void); > #else > static inline void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) {} > static inline void kvm_clr_pmu_events(u32 clr) {} > + > +static inline void setup_kvm_el2_caps(void) {} > #endif > > void kvm_vcpu_load_sysregs_vhe(struct kvm_vcpu *vcpu); > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 066030717a4c..6252476e4e73 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -1154,6 +1154,18 @@ u64 read_sanitised_ftr_reg(u32 id) > } > EXPORT_SYMBOL_GPL(read_sanitised_ftr_reg); > > +int copy_ftr_reg(u32 id, struct arm64_ftr_reg *dst) > +{ > + struct arm64_ftr_reg *regp = get_arm64_ftr_reg(id); > + > + if (!regp) > + return -EINVAL; > + > + *dst = *regp; > + > + return 0; > +} > + > #define read_sysreg_case(r) \ > case r: val = read_sysreg_s(r); break; > > @@ -2773,6 +2785,7 @@ void __init setup_cpu_features(void) > > setup_system_capabilities(); > setup_elf_hwcaps(arm64_elf_hwcaps); > + setup_kvm_el2_caps(); > > if (system_supports_32bit_el0()) > setup_elf_hwcaps(compat_elf_hwcaps); > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 4f2f1e3145de..6c5d133689ae 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2775,3 +2776,21 @@ void kvm_sys_reg_table_init(void) > /* Clear all higher bits. */ > cache_levels &= (1 << (i*3))-1; > } > + > +#define CPU_FTR_REG_HYP_COPY(id, name) \ > + { .sys_id = id, .dst = (struct arm64_ftr_reg *)&kvm_nvhe_sym(name) } > +struct __ftr_reg_copy_entry { > + u32 sys_id; > + struct arm64_ftr_reg *dst; > +} hyp_ftr_regs[] __initdata = { > +}; > + > +void __init setup_kvm_el2_caps(void) > +{ > + int i; > + > + for (i = 0; i < ARRAY_SIZE(hyp_ftr_regs); i++) { > + WARN(copy_ftr_reg(hyp_ftr_regs[i].sys_id, hyp_ftr_regs[i].dst), > + "%u feature register not found\n", hyp_ftr_regs[i].sys_id); > + } > +} > -- > 2.31.0.rc2.261.g7f71774620-goog > > I can't say I'm thrilled with this. Actually, it is fair to say that I don't like it at all! ;-) Copying whole structures with pointers that make no sense at EL2 feels... wrong. As we discussed offline, the main reason for this infrastructure is that the read_ctr macro directly uses arm64_ftr_reg_ctrel0.sys_val when ARM64_MISMATCHED_CACHE_TYPE is set. One thing to realise is that with the protected mode, we can rely on patching as there is no such thing as a "late" CPU. So by specialising read_ctr when compiled for nVHE, we can just make it give us the final value, provided that KVM's own __flush_dcache_area() is limited to protected mode. Once this problem is solved, this whole patch can mostly go, as we are left with exactly *two* u64 quantities to be populated, something that we can probably do in kvm_sys_reg_table_init(). I'll post some patches later today to try and explain what I have in mind. 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