From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 058821DFE1; Fri, 27 Jun 2025 13:12:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751029953; cv=none; b=o0xoDAi0Kfl4ummYP+C+zSAUCFOVRzx4TGjcq1womL+ZzWmUlzha+Mj0/PaTert/lX6G1gZ1tbCtRY6zwm0ZFWJ2gujctG4zFtrPRGhR6jM8ubTv1TMfu8HUaTp/QkbVp7K/PP4ebEux5ubnagvF8pBMEFskPgd0AALosrXKxtM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751029953; c=relaxed/simple; bh=Q6l1BxiwXFJKVXwA6TiA3L7Wf54iRrkNwkTuo2v5rJo=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=exSIYv3qR0FylJJQp0CeNccSNFvkmlSlxtKoNktJ/+6srk62ndJwkMLniQ/cBp1bmxQ7ySBoxb2ciXsHk5DdN18GiT/iCH4F1Q55WAekUkhx78KTrNVkbWuHTSElwn7aQvg9RuJl4kbpIGXJSWHlZAPLPOpsBHwN7DbX1mvJ1QU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SyxSP074; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SyxSP074" 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) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.