Message ID | 20240110075739.8291-1-tianruidong@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-21807-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp644478dyi; Wed, 10 Jan 2024 00:05:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IFDCOq3prMXcvm8FNGW1Sv4WbbCvAQo+kuioLhyILbJTYIKdVU4eOiO6E9oARrGoBR6oiVm X-Received: by 2002:a05:6a00:929d:b0:6d9:8f4f:5fe0 with SMTP id jw29-20020a056a00929d00b006d98f4f5fe0mr905852pfb.12.1704873909130; Wed, 10 Jan 2024 00:05:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704873909; cv=none; d=google.com; s=arc-20160816; b=JzKT+i5evr1ds+swUG1jItr7GU+A3vCBoGaf4eAxV2vxstveWzVDSyo6N0lWo7P609 BMiubdD0fgpFVTqxwKHOZD/b4p+bpoo7px59UFyO97VPF99iWvEvkVBvUOn4qXVjcyjQ WMVzkEuIYZOt3ZeMpfFrXykR5ujV8XuLBBIVWoO5ywMUijXS+wJg5/ighKR+xHvB20yc OiWT3V16jSHCSR9oSWihhHMq7sdHKJJuVzEO2M47W96XNa/1/Pw6XH9ecua+mObDXFn8 R8/vwtDsG4VMyr+NjTsI0N0SLkS6NM5Cya+DmKIsduCUSblkjNTJgeq7UMh68s8NL6Dm cijg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=nbdb4E7PxOFlixXUAaK8ICvnKq4HkQLsmvKPwWS8kDA=; fh=OHMI6+8LtBMEh2x4i2g5KNihsso91CHnuh0zBF5DUnU=; b=r6ANMTbDMQbkw6PbS/bkOozy4skCnggsC9afHOS2Ih0V6UdS3ALECpxSWV4YIHi83P KZqDNlaq13EV595YMlp17GzynbjYXolLQ0Y+7j9mtzcZReTirnMnWyjwS9BxH+5BxhbD ND51rAJVs0EotyuQ9QNBWtAof5vYvSOsDg+Ar1SVy1F7IQqrMR7p4SxetfQm4zo4vdXV Gawyb+7KDBVCDOc9hAlKObT2Vy7sMgUC7tIOE/LG/HneUoKq0Gwd5XGp04fofPA7AOSR B8QUhEs05owa2FoCNiMksJFxPjMbUrGYkEfV5ZteLo/5qiYvyK2BDBxIqxtH0/uZhCxI Jwqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-21807-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21807-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id j191-20020a6380c8000000b0059b64b153f6si3008004pgd.845.2024.01.10.00.05.09 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 00:05:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21807-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-21807-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21807-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D121D28A51C for <ouuuleilei@gmail.com>; Wed, 10 Jan 2024 07:58:05 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C8F3E3E49B; Wed, 10 Jan 2024 07:57:55 +0000 (UTC) Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E87D13E460 for <linux-kernel@vger.kernel.org>; Wed, 10 Jan 2024 07:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R541e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046050;MF=tianruidong@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0W-LGmrI_1704873460; Received: from localhost(mailfrom:tianruidong@linux.alibaba.com fp:SMTPD_---0W-LGmrI_1704873460) by smtp.aliyun-inc.com; Wed, 10 Jan 2024 15:57:43 +0800 From: Ruidong Tian <tianruidong@linux.alibaba.com> To: kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: maz@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, Ruidong Tian <tianruidong@linux.alibaba.com> Subject: [PATCH] KVM: arm64: Add missing ERX*_EL1 registers Date: Wed, 10 Jan 2024 15:57:39 +0800 Message-Id: <20240110075739.8291-1-tianruidong@linux.alibaba.com> X-Mailer: git-send-email 2.33.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787689863922374495 X-GMAIL-MSGID: 1787689863922374495 |
Series |
KVM: arm64: Add missing ERX*_EL1 registers
|
|
Commit Message
Ruidong Tian
Jan. 10, 2024, 7:57 a.m. UTC
Commit 464f2164da7e ("arm64: Add missing ERX*_EL1 encodings") add some
new RAS registers. Trap them to kvm.
Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com>
---
arch/arm64/kvm/sys_regs.c | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Wed, 10 Jan 2024 07:57:39 +0000, Ruidong Tian <tianruidong@linux.alibaba.com> wrote: > > Commit 464f2164da7e ("arm64: Add missing ERX*_EL1 encodings") add some > new RAS registers. Trap them to kvm. Well, they *are* already trapped by virtue of HCR_EL2.FIEN being 0. They are lacking a trap handler though. > > Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> > --- > arch/arm64/kvm/sys_regs.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 30253bd19917..76a9ba155d58 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -2389,8 +2389,13 @@ static const struct sys_reg_desc sys_reg_descs[] = { > { SYS_DESC(SYS_ERXCTLR_EL1), trap_raz_wi }, > { SYS_DESC(SYS_ERXSTATUS_EL1), trap_raz_wi }, > { SYS_DESC(SYS_ERXADDR_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_ERXPFGF_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_ERXPFGCTL_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_ERXPFGCDN_EL1), trap_raz_wi }, > { SYS_DESC(SYS_ERXMISC0_EL1), trap_raz_wi }, > { SYS_DESC(SYS_ERXMISC1_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_ERXMISC2_EL1), trap_raz_wi }, > + { SYS_DESC(SYS_ERXMISC3_EL1), trap_raz_wi }, > > MTE_REG(TFSR_EL1), > MTE_REG(TFSRE0_EL1), If my reading of the ARM ARM is correct, these registers only exist if FEAT_RASv1p1 is implemented. Which means that we shouldn't handle those as RAZ/WI unconditionally, but instead check for what we advertise to the guest and handle it accordingly. Thanks, M.
On Wed, Jan 10, 2024 at 12:20:30PM +0000, Marc Zyngier wrote: > If my reading of the ARM ARM is correct, these registers only exist if > FEAT_RASv1p1 is implemented. Which means that we shouldn't handle > those as RAZ/WI unconditionally, but instead check for what we > advertise to the guest and handle it accordingly. Can we go a step further and just stop advertising RAS to guests? I don't expect VMs to gain much from our RAZ/WI implementation. Conditional RAZ/WI would still be helpful in this case for migrated VMs that have 'seen' the feature.
Hi Oliver, On 15/01/2024 14:47, Oliver Upton wrote: > On Wed, Jan 10, 2024 at 12:20:30PM +0000, Marc Zyngier wrote: >> If my reading of the ARM ARM is correct, these registers only exist if >> FEAT_RASv1p1 is implemented. Which means that we shouldn't handle >> those as RAZ/WI unconditionally, but instead check for what we >> advertise to the guest and handle it accordingly. > > Can we go a step further and just stop advertising RAS to guests? I don't > expect VMs to gain much from our RAZ/WI implementation. These CPU registers would describe the error in a kernel-first setup, but firmware-first has its own in-memory way of doing that. The CPU features indicates the IESB feature and ESB-instruction exist to fence errors, and that the CPU uses the ESR_ELx.{S,A}ET bits to describe the CPU state after an error. These are all useful as part of the notification of an error, be that kernel-first or firmware-first. When its supported by the hardware, the VMM can inject an asynchronous external abort using KVM_GET_VCPU_EVENTS - otherwise the ESR_ELx.ISS bits are all imp-def, meaning all errors are catastrophic. Doing this would skip save/restore of VDISR_EL2, is there any other reason to do it? > Conditional > RAZ/WI would still be helpful in this case for migrated VMs that have > 'seen' the feature. Thanks, James
Hi James, On Mon, Jan 15, 2024 at 05:21:19PM +0000, James Morse wrote: > Hi Oliver, > > On 15/01/2024 14:47, Oliver Upton wrote: > > On Wed, Jan 10, 2024 at 12:20:30PM +0000, Marc Zyngier wrote: > >> If my reading of the ARM ARM is correct, these registers only exist if > >> FEAT_RASv1p1 is implemented. Which means that we shouldn't handle > >> those as RAZ/WI unconditionally, but instead check for what we > >> advertise to the guest and handle it accordingly. > > > > Can we go a step further and just stop advertising RAS to guests? I don't > > expect VMs to gain much from our RAZ/WI implementation. > > These CPU registers would describe the error in a kernel-first setup, but firmware-first > has its own in-memory way of doing that. > > The CPU features indicates the IESB feature and ESB-instruction exist to fence errors, and > that the CPU uses the ESR_ELx.{S,A}ET bits to describe the CPU state after an error. These > are all useful as part of the notification of an error, be that kernel-first or > firmware-first. > > When its supported by the hardware, the VMM can inject an asynchronous external abort > using KVM_GET_VCPU_EVENTS - otherwise the ESR_ELx.ISS bits are all imp-def, meaning all > errors are catastrophic. > > Doing this would skip save/restore of VDISR_EL2, is there any other reason to do it? Forgive me, had the blinders on and was thinking only of the error record interface, not ESB/DISR. In that context it makes a lot less sense to hide RAS from guests, especially if the guest depends on ESB being a NOP if the hardware doesn't support it.
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 30253bd19917..76a9ba155d58 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -2389,8 +2389,13 @@ static const struct sys_reg_desc sys_reg_descs[] = { { SYS_DESC(SYS_ERXCTLR_EL1), trap_raz_wi }, { SYS_DESC(SYS_ERXSTATUS_EL1), trap_raz_wi }, { SYS_DESC(SYS_ERXADDR_EL1), trap_raz_wi }, + { SYS_DESC(SYS_ERXPFGF_EL1), trap_raz_wi }, + { SYS_DESC(SYS_ERXPFGCTL_EL1), trap_raz_wi }, + { SYS_DESC(SYS_ERXPFGCDN_EL1), trap_raz_wi }, { SYS_DESC(SYS_ERXMISC0_EL1), trap_raz_wi }, { SYS_DESC(SYS_ERXMISC1_EL1), trap_raz_wi }, + { SYS_DESC(SYS_ERXMISC2_EL1), trap_raz_wi }, + { SYS_DESC(SYS_ERXMISC3_EL1), trap_raz_wi }, MTE_REG(TFSR_EL1), MTE_REG(TFSRE0_EL1),