Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5234941rwb; Tue, 6 Sep 2022 22:28:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR4JT2KOHNNgC9jJxk+j6PQHkZEGdGvGhtL9XEnftfF1sXeP/PVpm97HsK5o6xClGYV+JoA3 X-Received: by 2002:a63:84c1:0:b0:434:b9db:b9d with SMTP id k184-20020a6384c1000000b00434b9db0b9dmr1932383pgd.397.1662528480676; Tue, 06 Sep 2022 22:28:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662528480; cv=none; d=google.com; s=arc-20160816; b=lnBoiIe/HTmkeb/V3z4oNheN2mAJen9QqnqDhgDRGM5T2LcJI3gFq0z4i7/OVhLnaa G09rM5kr4tO0t+vv5296SnxpfGPPVVwoq0XQkw4G/XYByO9s1LzQnZIJG/mGxPgxaPY0 SI5SO45ELnC57/qG+L6sIsYOYgs5HrIyrkjFFPneNAcjgAWZjUlNBJndqoqTHhcMRbh1 VBBu9RMWEEDAjbMXv94zzM9zBIFLbnanIRI3OuRFckPXZbtJ7QteaxG/HLZwH9U7GsQy UK7WgTk21XCar13Mr5NBO9n798y7V92c7bLLKH6YgfeCjWbw6LTQoXHsd0pe/SpJDbsC V2xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=IB8D7t/VEzk35ELr98MItPXiflxE6OsuKH8uCTmfVu0=; b=jWWHJtuTIDvacYbDEKfDVB5zzFH4gmK3IBvpVr+fR/6SPOYaE91vO5sugCXYmWE7oV CrnRMz/toaVzDjNey+HURXLuKMtlgZPr6lk0Qi4iaFwS2wg1ZYPyji8uCS01XiCCvkgJ mVrY4viQVYWx85tvk5mP00POEabLBpGfOnVZvVr3UWUsi0BjNYokG0YND6dsJWaNdy16 vl14h9mHyO1HpcvB9fduagqcVVv3NW6Dk4LedTpPV2Kb4m7EyyUnqsuTffb/gzwYy0go TcLDkWfl7+kUEbaNTzWnT48xCbKmquoxUBQCoCW+3FAY5Iew3BRa/HR0zH1YG+kfG1hs V4ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="N1hXa/JW"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i1-20020a628701000000b00534eb9da2e7si15273840pfe.304.2022.09.06.22.27.48; Tue, 06 Sep 2022 22:28:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="N1hXa/JW"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229619AbiIGExO (ORCPT + 99 others); Wed, 7 Sep 2022 00:53:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiIGExL (ORCPT ); Wed, 7 Sep 2022 00:53:11 -0400 Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B7FB8036B for ; Tue, 6 Sep 2022 21:53:10 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id k2so13734504vsk.8 for ; Tue, 06 Sep 2022 21:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=IB8D7t/VEzk35ELr98MItPXiflxE6OsuKH8uCTmfVu0=; b=N1hXa/JWneN7X9IKmS2ao6iy9YLDaictBmMhbFg9cxBE0NkduKrzAFcYl/y/xmoyzt 3xH52+Rrdxv1/XQHNpBESXIuZb04hiO8kTyT5HpGbf32y40cBBgBt72l7BapgBjNFcx4 zS/Ng4Kpxj1EsZ9Umceh5gRXPh2dfwTZ3IN3pc46taHI4yt8KPpEz3UMHC8sFRmcJ4XB LaWRtRKHYlXpNuRfvtU8CSlYXws1Yfxg9QQxhizldcDJgXvUC00ImExcNMF6UMhuHW1B adGT/aC3XvK7X45UkNBLfAM5f6lPc59hCxPJh/Li/4DwqzGSDk9ihVf/C0ZcVmCBFcAp Y8GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=IB8D7t/VEzk35ELr98MItPXiflxE6OsuKH8uCTmfVu0=; b=QZ4eochZjFasNof7T0XO1I3lyB9EF7VTLbeS/q0Qx3LpP8tr5EERfKmPUDDaWgPu+l sh5TlFTJ5AzTeXg40XPF5SJzMas4amFy54r8izysCMnBPTJ4Cw/Mi8OnuEJ0HrHiN0TP mnLdYPItVg5uPveFd/ckRIN1czrgevPOZu0OabCQPPdcLqqz/RR5S+TAmvOndOTps/Pw ZvGZz4+p1tqNTzxdhQaYkFwUCA516+VOIYVOt8nwaq7jATCj56MnMwxZpyjzT3OLbXMB HZg7ymOgGFJgAjQN7OCZ4gMEmuP1TvYHP7kOFvatkO/34Id1S/OBRdd1ETebrYeDI6ik p+TA== X-Gm-Message-State: ACgBeo2ux8PK2nv/kqCwk5d162UcAMF69Qh+rNy6VhmPKznXtYTUvikM dWztvDdL/5Vc0qHB2NTYwHikqSVzQIIfgUEtNNIJyw== X-Received: by 2002:a67:b009:0:b0:38a:e0f2:4108 with SMTP id z9-20020a67b009000000b0038ae0f24108mr514173vse.9.1662526389280; Tue, 06 Sep 2022 21:53:09 -0700 (PDT) MIME-Version: 1.0 References: <20220902154804.1939819-1-oliver.upton@linux.dev> <20220902154804.1939819-7-oliver.upton@linux.dev> In-Reply-To: <20220902154804.1939819-7-oliver.upton@linux.dev> From: Reiji Watanabe Date: Tue, 6 Sep 2022 21:52:53 -0700 Message-ID: Subject: Re: [PATCH v2 6/7] KVM: arm64: Treat 32bit ID registers as RAZ/WI on 64bit-only system To: Oliver Upton Cc: Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Will Deacon , Linux ARM , kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oliver, On Fri, Sep 2, 2022 at 8:48 AM Oliver Upton wrote: > > One of the oddities of the architecture is that the AArch64 views of the > AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any EL. > Nonetheless, KVM exposes these registers to userspace for the sake of > save/restore. It is possible that the UNKNOWN value could differ between > systems, leading to a rejected write from userspace. > > Avoid the issue altogether by handling the AArch32 ID registers as > RAZ/WI when on an AArch64-only system. > > Signed-off-by: Oliver Upton > --- > arch/arm64/kvm/sys_regs.c | 63 ++++++++++++++++++++++++++------------- > 1 file changed, 43 insertions(+), 20 deletions(-) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 6d0511247df4..9569772cf09a 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1144,6 +1144,20 @@ static unsigned int id_visibility(const struct kvm_vcpu *vcpu, > return 0; > } > > +static unsigned int aa32_id_visibility(const struct kvm_vcpu *vcpu, > + const struct sys_reg_desc *r) > +{ > + /* > + * AArch32 ID registers are UNKNOWN if AArch32 isn't implemented at any > + * EL. Promote to RAZ/WI in order to guarantee consistency between > + * systems. > + */ > + if (!kvm_supports_32bit_el0()) > + return REG_RAZ | REG_USER_WI; > + > + return id_visibility(vcpu, r); > +} > + > static unsigned int raz_visibility(const struct kvm_vcpu *vcpu, > const struct sys_reg_desc *r) > { > @@ -1331,6 +1345,15 @@ static unsigned int mte_visibility(const struct kvm_vcpu *vcpu, > .visibility = id_visibility, \ > } > > +/* sys_reg_desc initialiser for known cpufeature ID registers */ > +#define AA32_ID_SANITISED(name) { \ > + SYS_DESC(SYS_##name), \ > + .access = access_id_reg, \ > + .get_user = get_id_reg, \ > + .set_user = set_id_reg, \ > + .visibility = aa32_id_visibility, \ > +} > + > /* > * sys_reg_desc initialiser for architecturally unallocated cpufeature ID > * register with encoding Op0=3, Op1=0, CRn=0, CRm=crm, Op2=op2 > @@ -1418,33 +1441,33 @@ static const struct sys_reg_desc sys_reg_descs[] = { > > /* AArch64 mappings of the AArch32 ID registers */ > /* CRm=1 */ > - ID_SANITISED(ID_PFR0_EL1), > - ID_SANITISED(ID_PFR1_EL1), > - ID_SANITISED(ID_DFR0_EL1), > + AA32_ID_SANITISED(ID_PFR0_EL1), > + AA32_ID_SANITISED(ID_PFR1_EL1), > + AA32_ID_SANITISED(ID_DFR0_EL1), > ID_HIDDEN(ID_AFR0_EL1), > - ID_SANITISED(ID_MMFR0_EL1), > - ID_SANITISED(ID_MMFR1_EL1), > - ID_SANITISED(ID_MMFR2_EL1), > - ID_SANITISED(ID_MMFR3_EL1), > + AA32_ID_SANITISED(ID_MMFR0_EL1), > + AA32_ID_SANITISED(ID_MMFR1_EL1), > + AA32_ID_SANITISED(ID_MMFR2_EL1), > + AA32_ID_SANITISED(ID_MMFR3_EL1), > > /* CRm=2 */ > - ID_SANITISED(ID_ISAR0_EL1), > - ID_SANITISED(ID_ISAR1_EL1), > - ID_SANITISED(ID_ISAR2_EL1), > - ID_SANITISED(ID_ISAR3_EL1), > - ID_SANITISED(ID_ISAR4_EL1), > - ID_SANITISED(ID_ISAR5_EL1), > - ID_SANITISED(ID_MMFR4_EL1), > - ID_SANITISED(ID_ISAR6_EL1), > + AA32_ID_SANITISED(ID_ISAR0_EL1), > + AA32_ID_SANITISED(ID_ISAR1_EL1), > + AA32_ID_SANITISED(ID_ISAR2_EL1), > + AA32_ID_SANITISED(ID_ISAR3_EL1), > + AA32_ID_SANITISED(ID_ISAR4_EL1), > + AA32_ID_SANITISED(ID_ISAR5_EL1), > + AA32_ID_SANITISED(ID_MMFR4_EL1), > + AA32_ID_SANITISED(ID_ISAR6_EL1), > > /* CRm=3 */ > - ID_SANITISED(MVFR0_EL1), > - ID_SANITISED(MVFR1_EL1), > - ID_SANITISED(MVFR2_EL1), > + AA32_ID_SANITISED(MVFR0_EL1), > + AA32_ID_SANITISED(MVFR1_EL1), > + AA32_ID_SANITISED(MVFR2_EL1), > ID_UNALLOCATED(3,3), > - ID_SANITISED(ID_PFR2_EL1), > + AA32_ID_SANITISED(ID_PFR2_EL1), > ID_HIDDEN(ID_DFR1_EL1), Perhaps it might be better to handle ID_AFR0_EL1 and ID_DFR1_EL1 in the same way as the other AArch32 ID registers for consistency ? (i.e. treat them RAZ/USER_WI instead of RAZ if kvm_supports_32bit_el0() is false instead of RAZ) Thank you, Reiji > - ID_SANITISED(ID_MMFR5_EL1), > + AA32_ID_SANITISED(ID_MMFR5_EL1), > ID_UNALLOCATED(3,7), > > /* AArch64 ID registers */ > -- > 2.37.2.789.g6183377224-goog >