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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37729C77B7A for ; Sat, 20 May 2023 08:45:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231294AbjETIpW (ORCPT ); Sat, 20 May 2023 04:45:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230419AbjETIpT (ORCPT ); Sat, 20 May 2023 04:45:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2FDFAB for ; Sat, 20 May 2023 01:45:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3E34F601B6 for ; Sat, 20 May 2023 08:45:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C459C433D2; Sat, 20 May 2023 08:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684572314; bh=Q2w/ZHIycmAJKSbj+m7Y7anZVkCPJuKGJTfDF1LoZR8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sKrkFr3KOMgw2ulTcx31zs7D1/06N7yrvEzIW//zw40XxQ3yCDriyrLsIp0/lVpRG 52nZFA8PyONX5oVNEBP8Q0gqyK1zzO4uY/chmR+FNSReUVEhFOjT9Ateg3Q+C1QKfI hfvug8ZwVue8bfQuOSF598Rdv+JJbtAFNiEtduCF4tUBGRwH/zEgCG5FHHcfynl636 0Qn1Lu0uErKduOCJF/yzwX1gVSE1vpauDIIQ8vyZJdgkin7sD3GT5jrDLhasJunR+O bhAcRwivC66rV5A3QEQS6PThOPWEzVpK54ZdJPv5bp6G8AXmiEifFYvCrh6sLabJ9y hcfTk331owHyQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1q0ID0-00Gh4i-9q; Sat, 20 May 2023 09:45:02 +0100 Date: Sat, 20 May 2023 09:45:01 +0100 Message-ID: <87y1ljo0he.wl-maz@kernel.org> From: Marc Zyngier To: "Jitindar Singh, Suraj" Cc: "jingzhangos@google.com" , "oupton@google.com" , "alexandru.elisei@arm.com" , "james.morse@arm.com" , "suzuki.poulose@arm.com" , "kvmarm@lists.linux.dev" , "rananta@google.com" , "linux-arm-kernel@lists.infradead.org" , "pbonzini@redhat.com" , "reijiw@google.com" , "will@kernel.org" , "kvm@vger.kernel.org" , "tabba@google.com" Subject: Re: [PATCH v8 6/6] KVM: arm64: Refactor writings for PMUVer/CSV2/CSV3 In-Reply-To: References: <20230503171618.2020461-1-jingzhangos@google.com> <20230503171618.2020461-7-jingzhangos@google.com> <7a4a7d86c851563d5ad631070611918906e92015.camel@amazon.com> <86bkigllzn.wl-maz@kernel.org> 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/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: surajjs@amazon.com, jingzhangos@google.com, oupton@google.com, alexandru.elisei@arm.com, james.morse@arm.com, suzuki.poulose@arm.com, kvmarm@lists.linux.dev, rananta@google.com, linux-arm-kernel@lists.infradead.org, pbonzini@redhat.com, reijiw@google.com, will@kernel.org, kvm@vger.kernel.org, tabba@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Sat, 20 May 2023 00:04:53 +0100, "Jitindar Singh, Suraj" wrote: >=20 > On Fri, 2023-05-19 at 10:16 +0100, Marc Zyngier wrote: > > CAUTION: This email originated from outside of the organization. Do > > not click links or open attachments unless you can confirm the sender > > and know the content is safe. > >=20 > >=20 > >=20 > > On Thu, 18 May 2023 22:08:15 +0100, > > "Jitindar Singh, Suraj" wrote: > > >=20 > > > Reading init_cpu_ftr_reg() is hurting my head :p but don't we have > > > basically 2 cases here? > > >=20 > > > 1. We are unaffected by spectre|meltdown i.e. > > > arm64_get_[spectre|meltdown]_v2_state() will return > > > SPECTRE_UNAFFECTED > > > and we will set the limit to 1 for the csv[1|2] bit fields in > > > read_sanitised_id_aa64pfr0_el1() > > >=20 > > > or > > >=20 > > > 2. We ARE affected by spectre|meltdown in which case > > > arm64_get_[spectre|meltdown]_v2_state() will be > > > SPECTRE_VULNERABLE|SPECTRE_MITIGATED in which case > > > read_sanitised_ftr_reg() will return a value with csv[1|2] set to 0 > > > essentially setting the limit for either of these bit fields to 0 > > > in > > > read_sanitised_id_aa64pfr0_el1(). > >=20 > > What is "WE"? >=20 > The CPU Hilarious. >=20 > >=20 > > >=20 > > > Are we trying to catch the case where csv[1|2] is 0 on the host but > > > we > > > are unaffected as detected by e.g. cpuid and that cpu happens to > > > incorrectly not set csv[1|2] in the ID register but we still want > > > to > > > allow the guest to see those bits as set? > > >=20 > > > This isn't really related to the CR as I know this is existing code > > > which has just been moved around and sorry if I'm missing something > > > obvious. > >=20 > > This code is called from *userspace*, and tries to cope with a VM > > being restored. So we have 3 (not 2 cases): > >=20 > > - both the source and the destination have the same level of CSVx > > =C2=A0 support, and all is great in the world > >=20 > > - the source has CSVx=3D=3D0, while the destination has CSVx=3D1. All g= ood, > > =C2=A0 as we won't be lying to the guest, and the extra mitigation > > =C2=A0 executed by the guest isn't a functional problem. The guest will > > =C2=A0 still see CSVx=3D0 after migration. > >=20 > > - the source has CSVx=3D1, while the destination has CSVx=3D0. This isn= 't > > =C2=A0 an acceptable situation, and we return an error > >=20 > > Is that clearer? >=20 > Yes thanks, that all makes sense. >=20 > My initial question was why we needed to enforce the limit essentially > twice in set_id_aa64pfr0_el1(). >=20 > Once with: > /* =20 > * Allow AA64PFR0_EL1.CSV2 to be set from userspace as long as > * it doesn't promise more than what is actually provided (the > * guest could otherwise be covered in ectoplasmic residue). > */ > csv2 =3D cpuid_feature_extract_unsigned_field(val, > ID_AA64PFR0_EL1_CSV2_SHIFT); > if (csv2 > 1 || > (csv2 && arm64_get_spectre_v2_state() !=3D > SPECTRE_UNAFFECTED)) > return -EINVAL; >=20 > /* Same thing for CSV3 */ > csv3 =3D cpuid_feature_extract_unsigned_field(val, > ID_AA64PFR0_EL1_CSV3_SHIFT); > if (csv3 > 1 || > (csv3 && arm64_get_meltdown_state() !=3D SPECTRE_UNAFFECTED)) > return -EINVAL; >=20 > And then again with the check in arm64_check_features(). Ah, I see what you mean. Yes, this isn't right. I asked for the generic code to be used in the past, but the old stuff was left in. Which is obviously not great. M. --=20 Without deviation from the norm, progress is not possible.