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 061E4286A7 for ; Mon, 17 Nov 2025 14:14:02 +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=1763388843; cv=none; b=aU1pkkEqo1hmTH5m4lPwNtDDfNXZLXlzre63z06V9RLriKQG3rW+qcEleBCnmlcHC2TCiiXkFi+wy5XvGGEilaSz+AoeMo9IPrs33UoUuMAC7Cn4OZrIGvUFEp59D1LCHe9AYP2Ve4ORGuwcbmLukGLm3R56+lOrF3ymGMmQz3U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763388843; c=relaxed/simple; bh=3jGSNpC+RFuosSSwTgsUJIaw5/p2K5A41jkysEQg2vk=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=DaPJaoJ9Xri25yRqDm7i38G79LX6dDXMteFryGKuHhh/+oUT3nZeCdtPHBjUjd9riB0wBtcBksb3hEbWkdlrYDuOD9QAMt1ealbrLrrv9BtaZ4/XRxr62i5b6PdN5pBBa9VkW3iblWs653MJmJmZobNPXh6JuklgqhuEU4JC7C8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uw54X+bn; 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="uw54X+bn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8665AC113D0; Mon, 17 Nov 2025 14:14:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763388842; bh=3jGSNpC+RFuosSSwTgsUJIaw5/p2K5A41jkysEQg2vk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uw54X+bni+oe6AiRl2/mPu19moxq8UVnxztvJe7wogGz7/YdeetTSPyyxYYIWx+TC d99XpRdSt68nfVhI8pLnU9KKOM94gdEaH74K3TwKsspk4cf8HrmHb2a9QMq6+p6+zx P2cELBf+7lfc8ZG3hSSCZj8BZUTw6gGuPYcduc6yhXscsDppAGH5QW3LWJg7+Q+zcJ Qq3HBa+F0DVXPawjSx5XKQQ5i8AOa5GZXkh8J0N4FRQA+tRfwa5imhuy3+S0ykd9x5 6XeZR3kRDiP9HdqOJHp1OReSZFlm4nXQaEcsuG71GU7WHHWYagKkdXpMJ0yP7/fA7D aIv1UZtTGHHTA== 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 1vKzzU-00000005r3X-1dPu; Mon, 17 Nov 2025 14:14:00 +0000 Date: Mon, 17 Nov 2025 14:14:00 +0000 Message-ID: <86zf8ksq53.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, Joey Gouly , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH 09/12] KVM: arm64: Add helper for swapping guest descriptor In-Reply-To: <20251112183406.2118981-10-oupton@kernel.org> References: <20251112183406.2118981-1-oupton@kernel.org> <20251112183406.2118981-10-oupton@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) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev 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: oupton@kernel.org, kvmarm@lists.linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 12 Nov 2025 18:34:03 +0000, Oliver Upton wrote: > > Implementing FEAT_HAFDBS in KVM's software PTWs requires the ability to > CAS a descriptor to update the in-memory value. Add an accessor to do > exactly that, coping with the fact that guest descriptors are in user > memory (duh). > > While FEAT_LSE required on any system that implements NV, KVM now uses > the stage-1 PTW for non-nested use cases meaning an LL/SC implementation > is necessary as well. > > Signed-off-by: Oliver Upton > --- > arch/arm64/include/asm/kvm_nested.h | 2 + > arch/arm64/kvm/at.c | 86 +++++++++++++++++++++++++++++ > 2 files changed, 88 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h > index 5d967b60414c..6dbc2908aed9 100644 > --- a/arch/arm64/include/asm/kvm_nested.h > +++ b/arch/arm64/include/asm/kvm_nested.h > @@ -403,4 +403,6 @@ void kvm_handle_s1e2_tlbi(struct kvm_vcpu *vcpu, u32 inst, u64 val); > (FIX_VNCR - __c); \ > }) > > +int __kvm_at_swap_desc(struct kvm *kvm, gpa_t ipa, u64 old, u64 new); > + > #endif /* __ARM64_KVM_NESTED_H */ > diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c > index a295a37dd3b1..74f3be46fa66 100644 > --- a/arch/arm64/kvm/at.c > +++ b/arch/arm64/kvm/at.c > @@ -1650,3 +1650,89 @@ int __kvm_find_s1_desc_level(struct kvm_vcpu *vcpu, u64 va, u64 ipa, int *level) > return ret; > } > } > + > +static int __lse_swap_desc(u64 __user *ptep, u64 old, u64 new) > +{ > + u64 tmp = old; > + int ret = 0; > + > + uaccess_enable_privileged(); > + > + asm volatile(__LSE_PREAMBLE > + "1: cas %[old], %[new], %[addr]\n" > + "2:\n" > + _ASM_EXTABLE_UACCESS_ERR(1b, 2b, %w[ret]) > + : [old] "+r" (old), [addr] "+Q" (*ptep), [ret] "+r" (ret) > + : [new] "r" (new) > + : "memory"); > + > + uaccess_disable_privileged(); > + > + if (ret) > + return ret; > + if (tmp != old) > + return -EAGAIN; > + > + return ret; > +} > + > +static int __llsc_swap_desc(u64 __user *ptep, u64 old, u64 new) > +{ > + unsigned int loops = 128; > + u64 tmp; > + int ret; > + > + uaccess_enable_privileged(); > + > + asm volatile("prfm pstl1strm, %[addr]\n" > + "1: ldxr %[tmp], %[addr]\n" > + "sub %[tmp], %[tmp], %[old]\n" > + "cbnz %[tmp], 3f\n" > + "2: stlxr %w[ret], %[new], %[addr]\n" > + "cbz %w[ret], 4f\n" > + "sub %w[loops], %w[loops], #1\n" > + "cbnz %w[loops], 1b\n" > + "3: mov %w[ret], %w[eagain]\n" > + "4:\n" > + : [ret] "=r" (ret), [addr] "+Q" (*ptep), [tmp] "=&r" (tmp), > + [loops] "+r" (loops) > + : [old] "r" (old), [new] "r" (new), [eagain] "Ir" (-EAGAIN) > + : "memory"); Why doesn't this need an exception table as well? I'd expect it to fault just as much as the LSE version (and ret cannot report -EFAULT, for example). I'm also on the fence about the bounded loop. Yes, forward progress is a problem, but it should only affect large systems which can readily use the atomic instructions. I'd rather we get rid of it until proven that we really need something like it. Thanks, M. -- Without deviation from the norm, progress is not possible.