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 A7B41D4979A for ; Tue, 3 Dec 2024 09:39:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LVy4fzr1ctQeI1kNYJhqvbZO8RMQAENJYVJs8RmiPjw=; b=nBNkXPkA+EWB7gBxA01IX8Kkq1 QLNyhJ4TG61UWRCX8linxGgVk0U4T8jmRSUxjcCZnIB9ODJ1G363Q9GSWUDbg2lFf6vSSicfqFInv Adwao76yoObJIU3JfLIWqAoydRs4t9NNB9146UeogQk5qjkH4bp1aSgtozT2Bk1C5dLkLCLw16xFQ hnVRTVbR6qVy1PrXynoBFWcAlID71gv0kkNwi0klzCGfxG9r23u03bESNcPPZv4TLz1BVJd2PyPVS 9+uSnkSqV2slw/6bBBz/dLCkpiZ0jS/xVfmzhe/PcP9sNZfxu2SLsG28Rt/1rhFPPHyfKM6GvTx0C sAaCCd5Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tIPNG-00000008vcJ-08fC; Tue, 03 Dec 2024 09:39:18 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tIPME-00000008vD2-3yoc for linux-arm-kernel@lists.infradead.org; Tue, 03 Dec 2024 09:38:16 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id ED240A41046; Tue, 3 Dec 2024 09:36:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D89C7C4CECF; Tue, 3 Dec 2024 09:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733218693; bh=rQ5TW4rFrG6qYjejx5fpKqPKvSS6CRZZUK/Q5K0MDv8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QhPYIwpxwd9nqFAUL5d17x0oJaAJ+KTmcr+RxiiZhe3ME0ryYuMY//UynJsU0GB6D hxLOAvCOnBzjkcD3Mc+UJiDfPpka9fca8mlnhXLtodkl4ED5DLfSip5kdAfIIsrQrR mvtxRTtAwIw8V/oMNSJKNSwCNB3dmVmwV/TAdeJjmcIOQhv8YD9UxrUsn6XaZaGKqt B9rPZRV1WG/n+eAhQAg01eLy01SWr0lvFKDtrkakCq717t2Zcs2UP4XLP0M+tbFJq/ U+8Uu3IDFinEXfTbYXzEL+kkOMaJENVi8zKYdSHJqAB5XgLnqJRuNoWTQHmoicG/h6 Hz4/dFHcadjLw== Received: from [104.132.45.111] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tIPMB-0002K5-Bc; Tue, 03 Dec 2024 09:38:11 +0000 Date: Tue, 03 Dec 2024 09:38:10 +0000 Message-ID: <87o71trtrx.wl-maz@kernel.org> From: Marc Zyngier To: Yicong Yang Cc: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 5/5] KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory In-Reply-To: <20241202135504.14252-6-yangyicong@huawei.com> References: <20241202135504.14252-1-yangyicong@huawei.com> <20241202135504.14252-6-yangyicong@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 104.132.45.111 X-SA-Exim-Rcpt-To: yangyicong@huawei.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, corbet@lwn.net, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, shuah@kernel.org, jonathan.cameron@huawei.com, shameerali.kolothum.thodi@huawei.com, linuxarm@huawei.com, prime.zeng@hisilicon.com, xuwei5@huawei.com, yangyicong@hisilicon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241203_013815_114533_2E3839C3 X-CRM114-Status: GOOD ( 29.05 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 02 Dec 2024 13:55:04 +0000, Yicong Yang wrote: > > From: Yicong Yang > > FEAT_LS64* instructions only support to access Device/Uncacheable > memory, otherwise a data abort for unsupported Exclusive or atomic Not quite. FEAT_LS64WB explicitly supports Write-Back mappings. > access (0x35) is generated per spec. It's implementation defined > whether the target exception level is routed and is possible to > implemented as route to EL2 on a VHE VM. Per DDI0487K.a Section > C3.2.12.2 Single-copy atomic 64-byte load/store: > > The check is performed against the resulting memory type after all > enabled stages of translation. In this case the fault is reported > at the final enabled stage of translation. > > If it's implemented as generate the DABT to the final enabled stage > (stage-2), inject a DABT to the guest to handle it. > > Signed-off-by: Yicong Yang > --- > arch/arm64/kvm/mmu.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index c9d46ad57e52..b7e6f0a27537 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -1787,6 +1787,20 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu) > return 1; > } > > + /* > + * If instructions of FEAT_{LS64, LS64_V, LS64_ACCDATA} operated on > + * unsupported memory regions, a DABT for unsupported Exclusive or > + * atomic access is generated. It's implementation defined whether > + * the exception will be taken to, a stage-1 DABT or the final enabled > + * stage of translation (stage-2 in this case as we hit here). Inject > + * a DABT to the guest to handle it if it's implemented as a stage-2 > + * DABT. > + */ > + if (esr_fsc_is_excl_atomic_fault(esr)) { > + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu)); > + return 1; > + } This doesn't seem quite right. This is injecting an *External* Data Abort, which is not what the spec says happens, as you are emulating the *first* acceptable behaviour: "The check is performed at each enabled stage of translation, and the fault is reported for the first stage of translation that provides an inappropriate memory type. In this case, the value of the HCR_EL2.DC bit does not cause accesses generated by the instructions to generate a stage 1 Data abort," So while the exception is reported at a different EL, the fault should still be an "unsupported Exclusive or atomic access". But that's also assuming that S2 has a device mapping, and it is EL1 that did something wrong. Surely you should check the IPA against its memory type? Further questions: what happens when a L2 guest triggers such fault? I don't think you can't arbitrarily route it back to L2 without looking at why it faulted. Thanks, M. -- Without deviation from the norm, progress is not possible.