[v2,2/2] arm64/kvm: Fine grain _EL2 system registers list that affect nested virtualization
Message ID | 20230925162057.27548-3-miguel.luis@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1544577vqu; Mon, 25 Sep 2023 16:15:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEm+KlfS+2xnb9OYG1PoCvTZbE4pSI0V1ygmGXkxiZgbqSZAFLrVz+OE4TMtjbmw/zUR2Tu X-Received: by 2002:a05:6a00:21d0:b0:68e:3eb6:d45 with SMTP id t16-20020a056a0021d000b0068e3eb60d45mr6740742pfj.30.1695683734195; Mon, 25 Sep 2023 16:15:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695683734; cv=none; d=google.com; s=arc-20160816; b=Veew/9TYZGqRXCCkJJrYY8pE6usyE5LsHr3seQLXhNGSd0S8N+/bpz/F0t5bQQY8h6 Q7T15zgsacDOj3azQ1X2WyVCK0YsGaniJnAfoSa7W1DY5KEn/n4btx3fqF9eiLMntczd kbrd1zSDV5KMjU9kRkLzExnM6dzbBBmkINasfNMjg8Y389eHNhxBfRbd0pwixvYFg8T5 aVZjRgWvp5/M294xMqp4Fd6fGOYcLY8IOYU/MpgY8jy/yjpSdDp3czwJ4X7nfpSVBi+O LhN85o7dCLMqQb/+u1NoWSrH0egxRSXlVIESqSXBQE+JL8Fcl+jxgQ1Z/EkJhHQOopIg zHDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=80bWNtyVFFb+A7R10PXNfmbF2WAi7Ns30GPR0ShRTfM=; fh=UEH6cFyH1ghvNrfwViNbncCn5r9iy89nkA/jfjQrZCI=; b=HbF3lOo8ZBRp6E7i6Vhn2edNMvuiFYOuFG+vTTExbbZOd3LhTLkmdc/hh/uMkjdzOE vsgzsQObLL4iPagkOEeaKTDgZ6KYS96p7qxzP0zD5b/oRJ2tcoP2aO8kr8nFSvLMs6nm xNCWs/8JxoIL3APhtBmFK9B0bGOr2hTI47V9U0/xm2YKHXo+pi1O+M10Bs/HGgxOLBUK xt+JlAErdbDNwkFEOrxgKq/TxTKV+snAujrHF1xClQjhhOGg6lUDONWNZati/1HbdENg 91UWnv19v9f+yjM64AdTydkIAdDL7okrif1+KsGgGb6FMo2vYSKqTGLNlfQYCrDDBzVU lb2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=WY7aM8ee; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id v20-20020a056a00149400b0068c01fba736si12116273pfu.301.2023.09.25.16.15.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 16:15:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=WY7aM8ee; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id AA8E38215785; Mon, 25 Sep 2023 09:22:58 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231695AbjIYQWw (ORCPT <rfc822;pusanteemu@gmail.com> + 29 others); Mon, 25 Sep 2023 12:22:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjIYQWv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 12:22:51 -0400 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47BA5E8 for <linux-kernel@vger.kernel.org>; Mon, 25 Sep 2023 09:22:44 -0700 (PDT) Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 38PECMDl017661; Mon, 25 Sep 2023 16:22:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=corp-2023-03-30; bh=80bWNtyVFFb+A7R10PXNfmbF2WAi7Ns30GPR0ShRTfM=; b=WY7aM8eevvIjOAFmJcvH681GQyveku4rM3CT4PhV9SYfqIvze4+ueMfNfbZ4jM2dq6vT OYAEWZX+gtCa8ZNW20257ipvXUkn6159/RpQ+FUZoEfT6P+qt3iOVB9ItYyQx33peW2p SajrmuqfplV6pluA/iNNSmw+tPd8ENR/TolhjE8Q+AUEolS+HWPDkMeiY2T2tCi+NIwm 2RBkfiiCJaQ6hgSOzatKoJDDuk8DiBSgIn4Rjk/sJU8Cg/+FbTVMWgZS0+d5k0HxV154 EMD348MBTY0nRfNEQfiem3lyhpNQ2Z0JJlZk8gbJjCebFcClCEZjoxPzKLpPxBYQW44C hg== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3t9pt3m4t1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Sep 2023 16:22:21 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 38PG8HfV034986; Mon, 25 Sep 2023 16:22:21 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3t9pf4ye89-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Sep 2023 16:22:20 +0000 Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 38PGLi22024071; Mon, 25 Sep 2023 16:22:20 GMT Received: from mlluis-mac.uk.oracle.com (dhcp-10-175-170-37.vpn.oracle.com [10.175.170.37]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id 3t9pf4ycur-3; Mon, 25 Sep 2023 16:22:20 +0000 From: Miguel Luis <miguel.luis@oracle.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>, Oliver Upton <oliver.upton@linux.dev>, James Morse <james.morse@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Zenghui Yu <yuzenghui@huawei.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev Cc: miguel.luis@oracle.com Subject: [PATCH v2 2/2] arm64/kvm: Fine grain _EL2 system registers list that affect nested virtualization Date: Mon, 25 Sep 2023 16:20:57 +0000 Message-Id: <20230925162057.27548-3-miguel.luis@oracle.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230925162057.27548-1-miguel.luis@oracle.com> References: <20230925162057.27548-1-miguel.luis@oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-09-25_13,2023-09-25_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 phishscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2309180000 definitions=main-2309250126 X-Proofpoint-ORIG-GUID: 0at01WG6PMWVVC80OzCSmus-Wdc347wc X-Proofpoint-GUID: 0at01WG6PMWVVC80OzCSmus-Wdc347wc X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 25 Sep 2023 09:22:58 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778053267193575796 X-GMAIL-MSGID: 1778053267193575796 |
Series |
Fine grain sysregs allowed to trap for nested virtualization
|
|
Commit Message
Miguel Luis
Sept. 25, 2023, 4:20 p.m. UTC
Some _EL1 registers got included in the _EL2 ranges, which are not
affected by NV. Remove them, fine grain the ranges to exclusively
include the _EL2 ones and fold SPSR/ELR _EL2 registers into the
existing range.
Signed-off-by: Miguel Luis <miguel.luis@oracle.com>
---
arch/arm64/kvm/emulate-nested.c | 44 ++++++++++++++++++++++++++++-----
1 file changed, 38 insertions(+), 6 deletions(-)
Comments
Hi Miguel, On 9/25/23 18:20, Miguel Luis wrote: > Some _EL1 registers got included in the _EL2 ranges, which are not if they aren't too many, you may list them as it eases the review > affected by NV. Remove them, fine grain the ranges to exclusively > include the _EL2 ones and fold SPSR/ELR _EL2 registers into the > existing range. > > Signed-off-by: Miguel Luis <miguel.luis@oracle.com> Fixes: d0fc0a2519a6 (" KVM: arm64: nv: Add trap forwarding for HCR_EL2") ? > --- > arch/arm64/kvm/emulate-nested.c | 44 ++++++++++++++++++++++++++++----- > 1 file changed, 38 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c > index 9ced1bf0c2b7..f6d0c87803f4 100644 > --- a/arch/arm64/kvm/emulate-nested.c > +++ b/arch/arm64/kvm/emulate-nested.c > @@ -649,14 +649,46 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = { > SR_TRAP(SYS_APGAKEYHI_EL1, CGT_HCR_APK), > /* All _EL2 registers */ > SR_RANGE_TRAP(sys_reg(3, 4, 0, 0, 0), > - sys_reg(3, 4, 3, 15, 7), CGT_HCR_NV), > + sys_reg(3, 4, 4, 0, 1), CGT_HCR_NV), > /* Skip the SP_EL1 encoding... */ > - SR_TRAP(SYS_SPSR_EL2, CGT_HCR_NV), > - SR_TRAP(SYS_ELR_EL2, CGT_HCR_NV), > - SR_RANGE_TRAP(sys_reg(3, 4, 4, 1, 1), > - sys_reg(3, 4, 10, 15, 7), CGT_HCR_NV), I am not sure I fully understand the sysreg encoding but globally there are not so many _EL2 regs trapped with .NV. And I can see holes within somes ranges defined above (I searched all "if EL2Enabled() && HCR_EL2.NV == '1' then" in the ARM ARM). Maybe I don't know how to use the ARM ARM doc but I feel difficult to understand if the "holes" within the encoding of some ranges are unused or are allocated to some other sysregs, which wouldn't be trapped by /NV. I fear range encoding may be quite risky. > + SR_RANGE_TRAP(sys_reg(3, 4, 4, 3, 0), > + sys_reg(3, 4, 10, 6, 7), CGT_HCR_NV), > + /* > + * Note that the spec. describes a group of MEC registers > + * whose access should not trap, therefore skip the following: > + * MECID_A0_EL2, MECID_A1_EL2, MECID_P0_EL2, > + * MECID_P1_EL2, MECIDR_EL2, VMECID_A_EL2, > + * VMECID_P_EL2. > + */ > SR_RANGE_TRAP(sys_reg(3, 4, 12, 0, 0), > - sys_reg(3, 4, 14, 15, 7), CGT_HCR_NV), > + sys_reg(3, 4, 12, 1, 1), CGT_HCR_NV), > + /* ICH_AP0R<m>_EL2 */ > + SR_RANGE_TRAP(SYS_ICH_AP0R0_EL2, > + SYS_ICH_AP0R3_EL2, CGT_HCR_NV), > + /* ICH_AP1R<m>_EL2 */ > + SR_RANGE_TRAP(SYS_ICH_AP1R0_EL2, > + SYS_ICH_AP1R3_EL2, CGT_HCR_NV), > + SR_RANGE_TRAP(sys_reg(3, 4, 12, 9, 5), > + sys_reg(3, 4, 12, 11, 7), CGT_HCR_NV), > + /* ICH_LR<m>_EL2 */ > + SR_RANGE_TRAP(SYS_ICH_LR0_EL2, > + SYS_ICH_LR7_EL2, CGT_HCR_NV), > + SR_RANGE_TRAP(SYS_ICH_LR8_EL2, > + SYS_ICH_LR15_EL2, CGT_HCR_NV), > + SR_RANGE_TRAP(sys_reg(3, 4, 13, 0, 1), > + sys_reg(3, 4, 13, 0, 7), CGT_HCR_NV), > + /* AMEVCNTVOFF0<n>_EL2 */ > + SR_RANGE_TRAP(sys_reg(3, 4, 13, 8, 0), > + sys_reg(3, 4, 13, 8, 7), CGT_HCR_NV), > + SR_RANGE_TRAP(sys_reg(3, 4, 13, 9, 0), > + sys_reg(3, 4, 13, 9, 7), CGT_HCR_NV), I think those 2 above ranges can be merged > + /* AMEVCNTVOFF1<n>_EL2 */ > + SR_RANGE_TRAP(sys_reg(3, 4, 13, 10, 0), > + sys_reg(3, 4, 13, 10, 7), CGT_HCR_NV), > + SR_RANGE_TRAP(sys_reg(3, 4, 13, 11, 0), > + sys_reg(3, 4, 13, 11, 7), CGT_HCR_NV), /* CNT*_EL2 */ > + SR_RANGE_TRAP(sys_reg(3, 4, 14, 0, 3), > + sys_reg(3, 4, 14, 5, 2), CGT_HCR_NV), > /* All _EL02, _EL12 registers */ > SR_RANGE_TRAP(sys_reg(3, 5, 0, 0, 0), > sys_reg(3, 5, 10, 15, 7), CGT_HCR_NV), not related to your patch but wrt the EL02 the only ones that I idenftied beeing trapped by NV using above search are CNTP_TVAL_EL02 3 5 14 2 0 CNTP_CTL_EL02 3 5 14 2 1 CNTP_CVAL_EL02 3 5 14 2 2 CNTV_TVAL_EL02 3 5 14 3 0 CNTV_CTL_EL02 3 5 14 3 1 CNTV_CVAL_EL02 3 5 14 3 2 Thanks Eric
Hi Eric, On 29/09/2023 15:08, Eric Auger wrote: > Hi Miguel, > On 9/25/23 18:20, Miguel Luis wrote: >> Some _EL1 registers got included in the _EL2 ranges, which are not > if they aren't too many, you may list them as it eases the review Thanks for bringing it up. Initially I thought those _EL1 registers would be ESR_EL1, TFSR_EL1 and FAR_EL1, but as I re-run through the process I cannot confirm the statement anymore. So that statement is a mistake now? I took as reference Table D18-2 on page D18-6307 where are listed instruction encodings for non-debug system register accesses. Having to deal with the document format is surely not an easy task, so I converted it to text using pdftotext -layout. After scraping, the end result is a table of encodings which we're allowed to sort/grep which may be handy to this when you consider the statement that all accesses (but the exceptions) to system registers ending in _EL2 should trap. >> affected by NV. Remove them, fine grain the ranges to exclusively >> include the _EL2 ones and fold SPSR/ELR _EL2 registers into the >> existing range. >> >> Signed-off-by: Miguel Luis <miguel.luis@oracle.com> > Fixes: d0fc0a2519a6 (" KVM: arm64: nv: Add trap forwarding for HCR_EL2") ? OK. >> --- >> arch/arm64/kvm/emulate-nested.c | 44 ++++++++++++++++++++++++++++----- >> 1 file changed, 38 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c >> index 9ced1bf0c2b7..f6d0c87803f4 100644 >> --- a/arch/arm64/kvm/emulate-nested.c >> +++ b/arch/arm64/kvm/emulate-nested.c >> @@ -649,14 +649,46 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = { >> SR_TRAP(SYS_APGAKEYHI_EL1, CGT_HCR_APK), >> /* All _EL2 registers */ >> SR_RANGE_TRAP(sys_reg(3, 4, 0, 0, 0), >> - sys_reg(3, 4, 3, 15, 7), CGT_HCR_NV), >> + sys_reg(3, 4, 4, 0, 1), CGT_HCR_NV), >> /* Skip the SP_EL1 encoding... */ >> - SR_TRAP(SYS_SPSR_EL2, CGT_HCR_NV), >> - SR_TRAP(SYS_ELR_EL2, CGT_HCR_NV), >> - SR_RANGE_TRAP(sys_reg(3, 4, 4, 1, 1), >> - sys_reg(3, 4, 10, 15, 7), CGT_HCR_NV), > I am not sure I fully understand the sysreg encoding but globally there > are not so many _EL2 regs trapped with .NV. And I can see holes within > somes ranges defined above (I searched all "if EL2Enabled() && > HCR_EL2.NV == '1' then" in the ARM ARM). Maybe I don't know how to use > the ARM ARM doc but I feel difficult to understand if the "holes" > within the encoding of some ranges are unused or are allocated to some > other sysregs, which wouldn't be trapped by /NV. I fear range encoding > may be quite risky. That's definitely fair and I share the same concerns too. Having table D18-2 sorted helped defining those ranges although I did not find the answer to those questions. Perhaps we could query for assumptions on the desired approach in which such implementation would rely. >> + SR_RANGE_TRAP(sys_reg(3, 4, 4, 3, 0), >> + sys_reg(3, 4, 10, 6, 7), CGT_HCR_NV), >> + /* >> + * Note that the spec. describes a group of MEC registers >> + * whose access should not trap, therefore skip the following: >> + * MECID_A0_EL2, MECID_A1_EL2, MECID_P0_EL2, >> + * MECID_P1_EL2, MECIDR_EL2, VMECID_A_EL2, >> + * VMECID_P_EL2. >> + */ >> SR_RANGE_TRAP(sys_reg(3, 4, 12, 0, 0), >> - sys_reg(3, 4, 14, 15, 7), CGT_HCR_NV), >> + sys_reg(3, 4, 12, 1, 1), CGT_HCR_NV), >> + /* ICH_AP0R<m>_EL2 */ >> + SR_RANGE_TRAP(SYS_ICH_AP0R0_EL2, >> + SYS_ICH_AP0R3_EL2, CGT_HCR_NV), >> + /* ICH_AP1R<m>_EL2 */ >> + SR_RANGE_TRAP(SYS_ICH_AP1R0_EL2, >> + SYS_ICH_AP1R3_EL2, CGT_HCR_NV), >> + SR_RANGE_TRAP(sys_reg(3, 4, 12, 9, 5), >> + sys_reg(3, 4, 12, 11, 7), CGT_HCR_NV), >> + /* ICH_LR<m>_EL2 */ >> + SR_RANGE_TRAP(SYS_ICH_LR0_EL2, >> + SYS_ICH_LR7_EL2, CGT_HCR_NV), >> + SR_RANGE_TRAP(SYS_ICH_LR8_EL2, >> + SYS_ICH_LR15_EL2, CGT_HCR_NV), >> + SR_RANGE_TRAP(sys_reg(3, 4, 13, 0, 1), >> + sys_reg(3, 4, 13, 0, 7), CGT_HCR_NV), >> + /* AMEVCNTVOFF0<n>_EL2 */ >> + SR_RANGE_TRAP(sys_reg(3, 4, 13, 8, 0), >> + sys_reg(3, 4, 13, 8, 7), CGT_HCR_NV), >> + SR_RANGE_TRAP(sys_reg(3, 4, 13, 9, 0), >> + sys_reg(3, 4, 13, 9, 7), CGT_HCR_NV), > I think those 2 above ranges can be merged Oh, indeed. For both AMEVCNTVOFF0<n>_EL2 and AMEVCNTVOFF1<n>_EL2. >> + /* AMEVCNTVOFF1<n>_EL2 */ >> + SR_RANGE_TRAP(sys_reg(3, 4, 13, 10, 0), >> + sys_reg(3, 4, 13, 10, 7), CGT_HCR_NV), >> + SR_RANGE_TRAP(sys_reg(3, 4, 13, 11, 0), >> + sys_reg(3, 4, 13, 11, 7), CGT_HCR_NV), > /* CNT*_EL2 */ OK. >> + SR_RANGE_TRAP(sys_reg(3, 4, 14, 0, 3), >> + sys_reg(3, 4, 14, 5, 2), CGT_HCR_NV), >> /* All _EL02, _EL12 registers */ >> SR_RANGE_TRAP(sys_reg(3, 5, 0, 0, 0), >> sys_reg(3, 5, 10, 15, 7), CGT_HCR_NV), > not related to your patch but wrt the EL02 the only ones that I > idenftied beeing trapped by NV using above search are > > CNTP_TVAL_EL02 3 5 14 2 0 > CNTP_CTL_EL02 3 5 14 2 1 > CNTP_CVAL_EL02 3 5 14 2 2 > CNTV_TVAL_EL02 3 5 14 3 0 > CNTV_CTL_EL02 3 5 14 3 1 > CNTV_CVAL_EL02 3 5 14 3 2 > That matches my search too. FWIW, below are the _EL12 from my search: AFSR0_EL12 3 5 5 1 0 AFSR1_EL12 3 5 5 1 1 AMAIR_EL12 3 5 5 3 0 CONTEXTIDR_EL12 3 5 13 0 1 CPACR_EL12 3 5 1 0 2 ESR_EL12 3 5 5 2 0 FAR_EL12 3 5 6 0 0 MAIR_EL12 3 5 10 2 0 SCTLR2_EL12 3 5 1 0 3 SCTLR_EL12 3 5 1 0 0 SMCR_EL12 3 5 1 2 6 TCR2_EL12 3 5 2 0 3 TCR_EL12 3 5 2 0 2 TFSR_EL12 3 5 5 6 0 TTBR0_EL12 3 5 2 0 0 TTBR1_EL12 3 5 2 0 1 VBAR_EL12 3 5 12 0 0 ZCR_EL12 3 5 1 2 0 TRFCR_EL12 3 5 1 2 1 PMSCR_EL12 3 5 9 9 0 CNTKCTL_EL12 3 5 14 1 0 Thanks Miguel > Thanks > > Eric >
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c index 9ced1bf0c2b7..f6d0c87803f4 100644 --- a/arch/arm64/kvm/emulate-nested.c +++ b/arch/arm64/kvm/emulate-nested.c @@ -649,14 +649,46 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = { SR_TRAP(SYS_APGAKEYHI_EL1, CGT_HCR_APK), /* All _EL2 registers */ SR_RANGE_TRAP(sys_reg(3, 4, 0, 0, 0), - sys_reg(3, 4, 3, 15, 7), CGT_HCR_NV), + sys_reg(3, 4, 4, 0, 1), CGT_HCR_NV), /* Skip the SP_EL1 encoding... */ - SR_TRAP(SYS_SPSR_EL2, CGT_HCR_NV), - SR_TRAP(SYS_ELR_EL2, CGT_HCR_NV), - SR_RANGE_TRAP(sys_reg(3, 4, 4, 1, 1), - sys_reg(3, 4, 10, 15, 7), CGT_HCR_NV), + SR_RANGE_TRAP(sys_reg(3, 4, 4, 3, 0), + sys_reg(3, 4, 10, 6, 7), CGT_HCR_NV), + /* + * Note that the spec. describes a group of MEC registers + * whose access should not trap, therefore skip the following: + * MECID_A0_EL2, MECID_A1_EL2, MECID_P0_EL2, + * MECID_P1_EL2, MECIDR_EL2, VMECID_A_EL2, + * VMECID_P_EL2. + */ SR_RANGE_TRAP(sys_reg(3, 4, 12, 0, 0), - sys_reg(3, 4, 14, 15, 7), CGT_HCR_NV), + sys_reg(3, 4, 12, 1, 1), CGT_HCR_NV), + /* ICH_AP0R<m>_EL2 */ + SR_RANGE_TRAP(SYS_ICH_AP0R0_EL2, + SYS_ICH_AP0R3_EL2, CGT_HCR_NV), + /* ICH_AP1R<m>_EL2 */ + SR_RANGE_TRAP(SYS_ICH_AP1R0_EL2, + SYS_ICH_AP1R3_EL2, CGT_HCR_NV), + SR_RANGE_TRAP(sys_reg(3, 4, 12, 9, 5), + sys_reg(3, 4, 12, 11, 7), CGT_HCR_NV), + /* ICH_LR<m>_EL2 */ + SR_RANGE_TRAP(SYS_ICH_LR0_EL2, + SYS_ICH_LR7_EL2, CGT_HCR_NV), + SR_RANGE_TRAP(SYS_ICH_LR8_EL2, + SYS_ICH_LR15_EL2, CGT_HCR_NV), + SR_RANGE_TRAP(sys_reg(3, 4, 13, 0, 1), + sys_reg(3, 4, 13, 0, 7), CGT_HCR_NV), + /* AMEVCNTVOFF0<n>_EL2 */ + SR_RANGE_TRAP(sys_reg(3, 4, 13, 8, 0), + sys_reg(3, 4, 13, 8, 7), CGT_HCR_NV), + SR_RANGE_TRAP(sys_reg(3, 4, 13, 9, 0), + sys_reg(3, 4, 13, 9, 7), CGT_HCR_NV), + /* AMEVCNTVOFF1<n>_EL2 */ + SR_RANGE_TRAP(sys_reg(3, 4, 13, 10, 0), + sys_reg(3, 4, 13, 10, 7), CGT_HCR_NV), + SR_RANGE_TRAP(sys_reg(3, 4, 13, 11, 0), + sys_reg(3, 4, 13, 11, 7), CGT_HCR_NV), + SR_RANGE_TRAP(sys_reg(3, 4, 14, 0, 3), + sys_reg(3, 4, 14, 5, 2), CGT_HCR_NV), /* All _EL02, _EL12 registers */ SR_RANGE_TRAP(sys_reg(3, 5, 0, 0, 0), sys_reg(3, 5, 10, 15, 7), CGT_HCR_NV),