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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 57C79C47077 for ; Tue, 16 Jan 2024 15:39:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TYaYUMhOIvEgAOBIxzgsQjln05XahYiT9aVyCBqGN64=; b=Hd2piCvvdwDoVH sxGc07FQdpqvcWPQpnBTyPLTWJZxeIl/u2coq0PCpdAQi+jiQkfTLmqhF/M1mD6Mj9suGKQSwH/N7 c67V8qLVx1KpjRqZeAR0Bs6YrI8wToAk0+hc5o8Hp7QwL1qHcs5Qy1qVDMMpgHmYyFoHRkq9SbjxT /PxLEobLKzvArl93ToZSYK8oHP1aCgHYuE+yCkA7nqljeRopmahYFJo8rk+pDGD3kxKrkGhrxfjZ/ OtrwU7UPXHYTjm6iERXxc+dV29MyOSHZapzeIAAGgIMqACYfaNyQ0f6KxELbb97YoxVXQ2UjFXSSQ uDXRIMWXwmH4dCs03uZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rPlWj-00CSZi-1v; Tue, 16 Jan 2024 15:38:57 +0000 Received: from out-171.mta0.migadu.com ([2001:41d0:1004:224b::ab]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rPlWg-00CSVw-1q for linux-arm-kernel@lists.infradead.org; Tue, 16 Jan 2024 15:38:56 +0000 Date: Tue, 16 Jan 2024 16:38:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1705419523; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZdUlkGvpg6AuVxEYLHDeazF0imgKqrZDbMjuhEMTD8o=; b=N3KoqCc5ehk6wxF6RAgNbMR7wj+PpGp16wLkvWqPN6tFdo0GnXEovVGkOVTdH2YmJ5gx/w h9KPhJ+kBh6w7gzt5tt6BcQVpiPwXphkiIFabnrFRe279DizAIRzQ4zEuaZo+6Mu2MSTV+ 3678SDcA5nA4JIsFvxrVHnX9dqr+3HE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: James Morse Cc: Marc Zyngier , 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 Subject: Re: [PATCH] KVM: arm64: Add missing ERX*_EL1 registers Message-ID: References: <20240110075739.8291-1-tianruidong@linux.alibaba.com> <867ckh9y7l.wl-maz@kernel.org> <67b15918-e9d3-97ea-65ca-985b5ddb3f88@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <67b15918-e9d3-97ea-65ca-985b5ddb3f88@arm.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240116_073855_061026_24EB0617 X-CRM114-Status: GOOD ( 20.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel