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 1C438C7EE31 for ; Fri, 27 Jun 2025 13:46:49 +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=LrFv2Pvv4nct7Z5khf5CGFiesli9tz1UfMgZVkAnWig=; b=0C0pw4gE3WwzgxPLvm6uiM0JSF h+1oH5xJdsJ6YeX7IyEqqD/W6uPKaSL1zEBoVVb2iDGfaJfy9Ix9+9Y9NUQQRD1GKhiHNRceOTeJn k7tiDZNphUSkoUomZNLUrV54uXGv++EJ3FffNpqe/mT+/AAUkXqFG2HlSZKnn1pATIK0A+crWBwJf zVrulZ52TcIBQDvUm4QgWyV8MVwh53aqVqBIsqQVt6GqSCbhdPnUD63Ewt+hD8/JWMAVuNudt50BJ 8UwzLQCxHr4umzlaApNHr5v4TzQYEtu+0fhpPIYOkUzV9fTOmRpGXwjf1X60ibwuzsIHpubb7TNAO si08TIdA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uV9Pf-0000000Eoig-2TPP; Fri, 27 Jun 2025 13:46:43 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uV8sc-0000000Ek4p-0gfj for linux-arm-kernel@lists.infradead.org; Fri, 27 Jun 2025 13:12:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 03F2EA52F00; Fri, 27 Jun 2025 13:12:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A07ECC4CEE3; Fri, 27 Jun 2025 13:12:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751029952; bh=Q6l1BxiwXFJKVXwA6TiA3L7Wf54iRrkNwkTuo2v5rJo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SyxSP074QoZcLTurytGAT4H9kzsOKMb6JhCvcMlKX4gwoPYlWBro+g8Vxdnrez6fS kRiHcTukK7xhlhSLD1z5fRXgfAPBmR+aolbdZ928nb0z3DE9kwpbPA8K9yUNph4dMA dV+jS1fD248e2GrFEBQbn+LG7GwNDempn63G92ZwflvZiDHuwuvhYFPXzub+0HwxaF 5897rGDwtPwmAbJ1fhQQWwe7P1WKGoI3Uu5EKSwcLZE/5h1Xyx5Jw9lTIpYxPcMMSz 8c6EcDYOgOxVIK2A52aqI0+xt38dznPiX0JFl8KENbUqi3d9MUjFhTArFC7WxhNc0J DZhakMlatKyiw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1uV8sY-00AZLe-8g; Fri, 27 Jun 2025 14:12:30 +0100 Date: Fri, 27 Jun 2025 14:12:29 +0100 Message-ID: <86v7ohba6a.wl-maz@kernel.org> From: Marc Zyngier To: , Yicong Yang Cc: , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v3 3/7] KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory In-Reply-To: <44993060-7eb1-400c-9887-3d438aeb8ee9@huawei.com> References: <20250626080906.64230-1-yangyicong@huawei.com> <20250626080906.64230-4-yangyicong@huawei.com> <86zfduc2ca.wl-maz@kernel.org> <44993060-7eb1-400c-9887-3d438aeb8ee9@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/30.1 (aarch64-unknown-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: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, yangyicong@huawei.com, yangyicong@hisilicon.com, catalin.marinas@arm.com, will@kernel.org, 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, tangchengchang@huawei.com, wangzhou1@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-20250627_061234_342788_467AF881 X-CRM114-Status: GOOD ( 34.51 ) 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 Thu, 26 Jun 2025 12:39:41 +0100, Yicong Yang wrote: > > On 2025/6/26 16:51, Marc Zyngier wrote: > > On Thu, 26 Jun 2025 09:09:02 +0100, > > Yicong Yang wrote: [...] > >> > >> + /* > >> + * Target address is normal memory on the Host. We come here > >> + * because: > >> + * 1) Guest map it as device memory and perform LS64 operations > >> + * 2) VMM report it as device memory mistakenly > >> + * Hand it to the userspace. > >> + */ > >> + if (esr_fsc_is_excl_atomic_fault(kvm_vcpu_get_esr(vcpu))) { > >> + struct kvm_run *run = vcpu->run; > >> + > >> + run->exit_reason = KVM_EXIT_ARM_LDST64B; > >> + run->arm_nisv.esr_iss = kvm_vcpu_dabt_iss_nisv_sanitized(vcpu); > >> + run->arm_nisv.fault_ipa = fault_ipa | > >> + (kvm_vcpu_get_hfar(vcpu) & (vma_pagesize - 1)); > >> + > >> + return -EAGAIN; > >> + } > > > > I'm not sure that's the right thing to do. > > > > If: > > > > - the guest was told it doesn't have LS64WB, > > > > - it was told that some range is memory, > > > > - it uses that range as device, > > > > - thanks to FWB the resulting memory type is "Normal-Cacheable" > > > > - which results in an Unsupported Atomic exception > > > > why would we involve the VMM at all? The VMM clearly said it didn't > > want to be involved in this (we have a memslot). > > > > ok I thought we should make VMM do the decision in all the cases(both > here and emulated MMIO) based on the last discussion[*], I may > misunderstand it. If this is the case... > > > I think we should simply inject the corresponding S1 fault back into > > the guest. > > > > let's simply inject a corresponding DABT back here and only make the VMM > handle the emulated MMIO case. will update if no further comment. A permission fault at S2 for a R/O memslot should definitely be relayed to userspace. But the question is whether the HW would report a permission fault or an unsupported atomic or exclusive fault (UAoEF for short). If the HW supports LS64WB, I'd fully expect to get a permission fault, not an UAoEF, and we can perfectly report this to userspace with full decode information (though this doesn't fit in the KVM_EXIT_MMIO structure -- that's "only" an ABI problem). If it doesn't, then we have a much bigger issue, and I don't think we can realistically triage the exception in a meaningful way -- we just can't know the reason why we failed, and we don't even know whether this was a load or store. Overall, I can see two options here: - we limit the LS64 support to HW that supports LS64WB (too bad for the other implementations, which is 100% of them). We can always triage the exception correctly, and we're unlikely to ever take an UAoEF in this context. - we define that R/O memslots do not support LS64 accesses at all, which is always a valid implementation -- the architecture makes no provision of which pieces of addressable memory supports an access type or another. With that, we can always inject the UAoEF back into the guest without any further triaging. Oliver, what do you think? M. -- Without deviation from the norm, progress is not possible.