From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C552A17C7B for ; Mon, 15 Jan 2024 17:21:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD97D2F4; Mon, 15 Jan 2024 09:22:09 -0800 (PST) Received: from [10.1.197.60] (eglon.cambridge.arm.com [10.1.197.60]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 709273F5A1; Mon, 15 Jan 2024 09:21:21 -0800 (PST) Message-ID: <67b15918-e9d3-97ea-65ca-985b5ddb3f88@arm.com> Date: Mon, 15 Jan 2024 17:21:19 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] KVM: arm64: Add missing ERX*_EL1 registers Content-Language: en-GB To: Oliver Upton , Marc Zyngier Cc: Ruidong Tian , kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org References: <20240110075739.8291-1-tianruidong@linux.alibaba.com> <867ckh9y7l.wl-maz@kernel.org> From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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