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 6F78BE77188 for ; Mon, 6 Jan 2025 11:14:23 +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=r4ata/yPH18mi4XtUuRMPfleFQhWEZgmuXg7sJ/wjms=; b=VPiXhnOKz5ELwSk96q91MtYqOJ CMn2zt4mBuj20f0306UXVnx0mAU61OSIdVDkixCEEDYi28df7DxgM3R/1bpjAVoA5UzG3TrWbjBUs vLl7pV7MeLiXMjzyx/eEcDSDwUdBZPZ4x1RNUUS+3e1mE6/bznBe2wjLEFX+kpwcw2baCo9vKUaal 1BlfgJrSzAiPU1aVoRehaWEWVSE5Jm/E82jHdMxu1nP5fAGNEGjqGEx5Qw57MNtiDX1BNE0nIiLYW fMKDXAqk/vXfZm4KK6ba7NXlDLOqYoWzFeODFGEKqZ6w2KJVZij/Nst6s/wgxkfx3pmdoLz818R6x QHtAE71g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tUl3j-000000010Hy-2lK1; Mon, 06 Jan 2025 11:14:11 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tUl2Y-000000010BQ-09Uf for linux-arm-kernel@lists.infradead.org; Mon, 06 Jan 2025 11:12:59 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id AFE7DA414D0; Mon, 6 Jan 2025 11:11:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36CD7C4CED2; Mon, 6 Jan 2025 11:12:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736161976; bh=f//ePYewEo6KUIJT7r9xdenXGO7+0Zhd9RhZAsOww8w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CulvJm0vRpKKcfnb/CxBgrC4q0kDVl6jLj+GAF/84BRZXQZ2QwohPAUlLMNefjafu IA2ZiRpnvUJINBu3L8Vd/S4VvlfldlN0oKoSt5AxE5MU/GR2piE7ga1ywAuxx7a6M4 oIsH06+7hhMx/MZFnWFJ65jynnWpT6tyQftHKDukOhs0YwKS+e1AvRHS+fOJjHmVMq TsMHy7dHIh/4stY1BR+KFiEZ+TTXM46Rush0MLuZByGNMd2nI1vvRCRNZ9S6+N/UST PsFaJvlMZSBb162EI+wqy5W16/wjbouYktui9oFGpzb/VViCTguMTxy75uWUnPKtbg nHCHPglS4WvyA== 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 1tUl2T-009NlL-Ta; Mon, 06 Jan 2025 11:12:54 +0000 Date: Mon, 06 Jan 2025 11:12:53 +0000 Message-ID: <868qrop556.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Mark Brown , stable@vger.kernel.org Subject: Re: [PATCH v2] arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented In-Reply-To: References: <20250103182255.1763739-1-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/29.4 (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: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org, 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250106_031258_235830_EDC6F2C6 X-CRM114-Status: GOOD ( 38.24 ) 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 Mon, 06 Jan 2025 09:40:56 +0000, Mark Rutland wrote: > > On Fri, Jan 03, 2025 at 06:22:55PM +0000, Marc Zyngier wrote: > > The hwcaps code that exposes SVE features to userspace only > > considers ID_AA64ZFR0_EL1, while this is only valid when > > ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported. > > > > The expectations are that when ID_AA64PFR0_EL1.SVE is 0, the > > ID_AA64ZFR0_EL1 register is also 0. So far, so good. > > > > Things become a bit more interesting if the HW implements SME. > > In this case, a few ID_AA64ZFR0_EL1 fields indicate *SME* > > features. And these fields overlap with their SVE interpretations. > > But the architecture says that the SME and SVE feature sets must > > match, so we're still hunky-dory. > > > > This goes wrong if the HW implements SME, but not SVE. In this > > case, we end-up advertising some SVE features to userspace, even > > if the HW has none. That's because we never consider whether SVE > > is actually implemented. Oh well. > > Ugh; this is a massive pain. :( > > Was this found by inspection, or is some real software going wrong? Catalin can comment on that -- I understand that he found existing SW latching on SVE2 being wrongly advertised as hwcaps. > > Fix it by restricting all SVE capabilities to ID_AA64PFR0_EL1.SVE > > being non-zero. > > Unfortunately, I'm not sure this fix is correct+complete. > > We expose ID_AA64PFR0_EL1 and ID_AA64ZFR0_EL1 via ID register emulation, > so any userspace software reading ID_AA64ZFR0_EL1 will encounter the > same surprise. If we hide that I'm worried we might hide some SME-only > information that isn't exposed elsewhere, and I'm not sure we can > reasonably hide ID_AA64ZFR0_EL1 emulation for SME-only (more on that > below). I don't understand where things go wrong. EL0 SW that looks at the ID registers should perform similar checks, and we are not trying to make things better on that front (we can't). Unless you invent time travel and fix the architecture 5 years ago... :-/ The hwcaps are effectively demultiplexing the ID registers, and they have to be exact, which is what this patch provides (SVE2 doesn't get wrongly advertised when not present). > Secondly, all our HWCAP documentation is written in the form: > > | HWCAP2_SVEBF16 > | Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001. > > ... so while the architectural behaviour is a surprise, the kernel is > (techincallyy) behaving exactly as documented prior to this patch. Maybe > we need to change that documentation? Again, I don't see what goes wrong here. BF16 is only implemented for SVE or SME+FA64, and FA64 requires SVE2. So at least for that one, we should be good. > > Do we have equivalent SME hwcaps for the relevant features? > > ... looking at: > > https://developer.arm.com/documentation/ddi0601/2024-12/AArch64-Registers/ID-AA64ZFR0-EL1--SVE-Feature-ID-Register-0?lang=en > > ... I see that ID_AA64ZFR0_EL1.B16B16 >= 0b0010 implies the presence of > SME BFMUL and BFSCALE instructions, but I don't see something equivalent > in ID_AA64SMFR0_EL1 per: > > https://developer.arm.com/documentation/ddi0601/2024-12/AArch64-Registers/ID-AA64SMFR0-EL1--SME-Feature-ID-Register-0?lang=en > > ... so I suspect ID_AA64ZFR0_EL1 might be the only source of truth for > this. Indeed, and the SME HWCAPs are not doing the right thing either. Or rather, we have no way to tell userspace that BFMUL/BFSCALE are available. > It is bizarre that ID_AA64SMFR0_EL1 doesn't follow the same format, and > ID_AA64SMFR0_EL1.B16B16 is a single-bit field that cannot encode the > same values as ID_AA64ZFR0_EL1.B16B16 (which is a 4-bit field). *everything* about SME is bizarre. > Even if we change Linux here, someone will need to chase up with the > architects to ensure this isn't made worse in future. Good luck! M. -- Without deviation from the norm, progress is not possible.