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 802F9C9832A for ; Tue, 29 Sep 2026 14:13:40 +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-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2Dk0LckhodBoHKrWlTBpRMQHe6Wk8ImTuZYBryUACZo=; b=C4a92N5WI7AS+Sd9RbdaSSebx8 hIGoLXtv8q0baSrn35/JS+Q6IrvhxT2q5XculPTAIL6ysrIl4kidnxGOQTVRv9Tz6HHj4qviEIiNy GMN83thIeMnaihKxT1ZqXCHseAB4OJyCfXW6uGqNHz/O3s4kyMH3w2SBW0hUIz6XhiTKB+IAfNC3T dLD5HTD6nOVM2EJ4+Mtq/CgPyeuRlYSNkP72ffYAYlnuWDFYV6Hagadnk9XLy7xsdc/TFvN839NRR AbsldpZoMdr+IQMQTOWUyE3hd3JB9o2bFmTd5SU0oCPP1DEtKlmHGV2TiFkz3bItf26MG6sgPuSkO 4tC3wRVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xBYaL-00000003lKN-34K5; Tue, 29 Sep 2026 14:13:33 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xBYaK-00000003lK2-2HGQ for linux-arm-kernel@lists.infradead.org; Tue, 29 Sep 2026 14:13:32 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id A043C60008; Tue, 29 Sep 2026 14:13:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56A781F000FF; Tue, 29 Sep 2026 14:13:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790691211; bh=2Dk0LckhodBoHKrWlTBpRMQHe6Wk8ImTuZYBryUACZo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ptw+rtCUl02YbGD2eAmr156Rdq4+2BStIyQCChm1r4K5TYo9ZXC4sSL5NzlImWci7 e1Wyo1lSuWTT6EM0h0Dx9hVkvRzAeEeRA+CUVFhBoVxAgwiHcLhMpDySdC3EpAfzr8 4pla3s37orME7jOdl3UU93yXB9bBsWzs6Iw1FwZbpgCgwaVYabZLvWZXIm1rg68qZw z7UzpR5GuRPnA9DmvHtmzDGrDpflTZ2cSwNHyfqij85jWc8wX47ARa7lCRvzXTWne0 elm5E5Htplv8tyNGcz9umtv9CBW9aatFmzaECL6GqAnQgBTZ1jRXAAzmfOEE8YrDg3 Vzv8QP4jnz2eQ== 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.98.2) (envelope-from ) id 1xBYaG-0000000Et43-3ZdE; Tue, 29 Sep 2026 14:13:28 +0000 Date: Tue, 29 Sep 2026 15:13:28 +0100 Message-ID: <86a4p0403b.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Steffen Eiden , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Yuchao Zhang , stable@vger.kernel.org Subject: Re: [PATCH v2 1/7] KVM: arm64: Move OUTSIDE_GUEST_MODE publication past context being saved In-Reply-To: References: <20260929093548.3598547-1-maz@kernel.org> <20260929093548.3598547-2-maz@kernel.org> 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 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: fuad.tabba@linux.dev, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, seiden@linux.ibm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, ndaugoing@gmail.com, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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 Tue, 29 Sep 2026 13:59:23 +0100, Fuad Tabba wrote: >=20 > Hi Marc, >=20 > On Tue, 29 Sep 2026 10:35:42 +0100, Marc Zyngier wrote: > [...] > > Move the publication of OUTSIDE_GUEST_MODE to the point where the state > > is actually written, and give this write release semantics to ensure the > > correct ordering. > > > > Signed-off-by: Marc Zyngier > > Cc: stable@vger.kernel.org >=20 >=20 > No Fixes: tag? No. It's always been fsck'd. >=20 > [...] > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > [...] > > @@ -1386,6 +1385,12 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcp= u) > > > > kvm_arch_vcpu_ctxsync_fp(vcpu); > > > > + /* > > + * All the state has been synchronised, let advertise > > + * we're outside of the guest. > > + */ > > + smp_store_release(&vcpu->mode, OUTSIDE_GUEST_MODE); >=20 > Pardon my atomics :) This is not an atomic instruction. However, it composes with atomics. > , but what does the release pair with? On the halt > path, the only reader I can find is the cmpxchg() in > kvm_vcpu_exiting_guest_mode() =46rom Documentation/atomic_t.txt: - RMW operations that have a return value are fully ordered; - RMW operations that are conditional are unordered on FAILURE, otherwise the above rules apply. The acquire side of cmpxchg() is therefore interacting with the above release, which gives us the required ordering. However, there is a problem if cmpxchg() fails, as there is no ordering in that case, and I'm not sure the smp_mb__before_atomic() saves the bacon in that case. It feels we'd need an acquire somewhere, a bit like this: diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 03bfc92864b6e..2efb4febcb235 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -563,9 +563,15 @@ static inline int kvm_vcpu_exiting_guest_mode(struct k= vm_vcpu *vcpu) * The memory barrier ensures a previous write to vcpu->requests cannot * be reordered with the read of vcpu->mode. It pairs with the general * memory barrier following the write of vcpu->mode in VCPU RUN. + * + * cmpxchg() is not ordered when failing, so make sure we perform an + * acquire in that case. */ smp_mb__before_atomic(); - return cmpxchg(&vcpu->mode, IN_GUEST_MODE, EXITING_GUEST_MODE); + if (cmpxchg(&vcpu->mode, IN_GUEST_MODE, EXITING_GUEST_MODE) !=3D IN_GUEST= _MODE) + return smp_load_acquire(&vcpu->mode); + + return IN_GUEST_MODE; } =20 /* > , and the LPI-disable and MOVALL halts > then take ap_list_lock or irq_lock. Would WRITE_ONCE() be enough? We need a release so that we know for sure that any state stored before is visible by the time we can observe OUTSIDE_GUEST_MODE, and WRITE_ONCE() doesn't provide that (it can be reordered). I don't see what taking a lock changes to the ordering requirement. > > Should the early exit path (the kvm_vcpu_exit_request() bail-out) get > the same treatment? I think that's what Sashiko is trying to say in > the patch 5 review [1]. I don't understand what sashiko is trying to say, but this is clearly missing from the patch, see below. Not sure how I missed that one. diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 9a4871cd796bc..1a3a15bc6f55c 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1333,13 +1333,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) smp_store_mb(vcpu->mode, IN_GUEST_MODE); =20 if (ret <=3D 0 || kvm_vcpu_exit_request(vcpu, &ret)) { - vcpu->mode =3D OUTSIDE_GUEST_MODE; isb(); /* Ensure work in x_flush_hwstate is committed */ if (kvm_vcpu_has_pmu(vcpu)) kvm_pmu_sync_hwstate(vcpu); if (unlikely(!irqchip_in_kernel(vcpu->kvm))) kvm_timer_sync_user(vcpu); kvm_vgic_sync_hwstate(vcpu); + smp_store_release(&vcpu->mode, OUTSIDE_GUEST_MODE); local_irq_enable(); preempt_enable(); continue; Thanks, M. --=20 Without deviation from the norm, progress is not possible.