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 E0B5423F27B for ; Tue, 11 Nov 2025 11:15:28 +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=1762859729; cv=none; b=o8mAF7xYR6F4aWioKXeD2o6eUI/M08TgCf/D+WBIaEYKZt4JekluizOOoGEf+77PbyDdGicslunf2t5z6dZH1nf3C5Ldb4ZFDqCHYXYDSD/jXRkjXvTDgZWrn3Vl+apZKdwk3BEWaezRbFpVtvQDX5oRXyUhCi9BxzM6Oa8E260= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762859729; c=relaxed/simple; bh=8esgnEfQShwsJTYAUF/LnkC8u1MGVSAO4Wul/tnrTjo=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=p6OBUZag/cFBXmQZ6NfM/r1Yhc67hnErB0Glh488dytprY2SDm5MK6R7lwsrK/b447nzLKt/TvEPgyVbSjMH6Dcard8repV6adgoZ83YV2Xmtr0DkzQkbW7xQscuHFXKvFDgoyXtcvpYC2qwJc5k7R4u2kHd9EsLXdd2K1NtXtw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fZk1GJON; 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="fZk1GJON" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF58C116D0; Tue, 11 Nov 2025 11:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762859728; bh=8esgnEfQShwsJTYAUF/LnkC8u1MGVSAO4Wul/tnrTjo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fZk1GJON3mQsh+um17ntocleBKoQ3IdtzBGfVDLLhdu7YLT3uTgScins5LnEpT2Uj GrN5A6yaPXgfQCTjWn55fozDxEu8RhyLLkrw3glfQMPBV8k2vnuk8PkdNHayLTwrX8 ldTl9pqSuhr8y2S2wsbBktiw7kbUsoE97WIKAS/jcUMDkxiQMHxsbO4wMXYTpV+vWc W12p+IKFTsLTCfZZ8ndpmWK5DLWdgraq5wIt/yP1GkCxsgjO1lG1rqidWvwRBPZx0Q rYBJMLRjD+ryE1gEHHyc1i81m0jQK3MSGhjjJGsPMBesCVZFllP4bVc8P9Z2ghp1XS 3g44LUqHaY7EA== 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 1vImLN-00000004Csl-3zca; Tue, 11 Nov 2025 11:15:26 +0000 Date: Tue, 11 Nov 2025 11:15:25 +0000 Message-ID: <861pm4vn02.wl-maz@kernel.org> From: Marc Zyngier To: Zhou Wang Cc: , , , , , , , , , , , Subject: Re: [PATCH v7 5/7] arm64: Add support for FEAT_{LS64, LS64_V} In-Reply-To: <20251107072127.448953-6-wangzhou1@hisilicon.com> References: <20251107072127.448953-1-wangzhou1@hisilicon.com> <20251107072127.448953-6-wangzhou1@hisilicon.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: 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: wangzhou1@hisilicon.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, yangyccccc@gmail.com, prime.zeng@hisilicon.com, xuwei5@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 Fri, 07 Nov 2025 07:21:25 +0000, Zhou Wang wrote: > > From: Yicong Yang > > Armv8.7 introduces single-copy atomic 64-byte loads and stores > instructions and its variants named under FEAT_{LS64, LS64_V}. > These features are identified by ID_AA64ISAR1_EL1.LS64 and the > use of such instructions in userspace (EL0) can be trapped. In > order to support the use of corresponding instructions in userspace: > - Make ID_AA64ISAR1_EL1.LS64 visbile to userspace > - Add identifying and enabling in the cpufeature list > - Expose these support of these features to userspace through HWCAP3 > and cpuinfo > > ld64b/st64b (FEAT_LS64) and st64bv (FEAT_LS64_V) is intended for > special memory (device memory) so requires support by the CPU, system > and target memory location (device that support these instructions). > The HWCAP3_{LS64, LS64_V} implies the support of CPU and system (since > no identification method from system, so SoC vendors should advertise > support in the CPU if system also support them). But this doesn't mean that the system actually supports this. It is also trivial for EL0 to spoof a PASID using ST64BV, by populating the bottom 32bit with whatever it wants (hiding ST64BV0 doesn't prevent this). In all honestly, I'm starting to think that we cannot safely expose this to userspace, at least not without strong guarantees coming from the system itself. Thanks, M. -- Without deviation from the norm, progress is not possible.