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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A3F4C83F16 for ; Sat, 26 Aug 2023 08:02:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231260AbjHZIBo (ORCPT ); Sat, 26 Aug 2023 04:01:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbjHZIBR (ORCPT ); Sat, 26 Aug 2023 04:01:17 -0400 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FCF51FD7 for ; Sat, 26 Aug 2023 01:01:10 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-401b393df02so15157035e9.1 for ; Sat, 26 Aug 2023 01:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1693036869; x=1693641669; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=8zeI6AUjlRlAi0IA4zOJ4FhSx5m+2z7V0zbKgXgsP9A=; b=R57hJHNjTKj/VEVKSt8dYUPyyXeow2ml98lOSYDxkU7RHCFR5yDkFFmWRViV5/GByr uDOekwb5fbx+0Gti3DO6w1UJiFJ5nf0b7H+Us29Odze8jV4uXk1OWUA+xhfazzeyRyv6 Zaix3hDh8kwgFoEfVJtJBFXkG9/YfBvOf15xqjo8d+bjbn3j8+21pnDXBj/2YGyXYgyw 4z1y3pHgYUTmcPtOi3ETJr3T4XefMDk9UlEXz92H7Htvb2ZYPt3zCifw/KFuuJGuhKX0 L45CD620XAp0ovJ3thFCrG3p6Hms29c8HJG6hCtuvium7AAbq437AVeyrtCxl18AEnV8 IFWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693036869; x=1693641669; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8zeI6AUjlRlAi0IA4zOJ4FhSx5m+2z7V0zbKgXgsP9A=; b=iqbPPQwJ1ci7Nh4ChRtFrPW/O9B2XQWJuaR90aH1a+nkRAETdrA9l3hGvN/47sK2eA Af8MtmO+aWxS8jdgYT7+PSJ7k7HVxN3u/f+5AFfEix/RNf/NkuXLe4YxKlMA+rX+Ayzw rOLYOGpLmw77eo7Mm20TfYmi11hQwmYIgnkLPATI0IGmyDUUcTHPKEOV1kng7UTroc3P DTX8AvxcWR30/Zg7XwkhDgKjAjmP7xxNAh4BJiPW4ktVGgLgzdC7zcuPgF66ugOId/5m Jbp1GNfzUcJsHb1f8f/qGa9YdS8toLgr5l2t8LheZmQBaZi7MAUCaaLA6F7iBQD6tbor YaOQ== X-Gm-Message-State: AOJu0Yz9Qh2A/xQ1oUwxJvxOrv58FV4aTqIeYAY6HRKu5tqUfGOV/K00 Ua6JD0X3VmH6rwkzUsLJAuf1Ew== X-Google-Smtp-Source: AGHT+IFip3zr5PD+wLFjohJxk2E8ZxQQ84TpALHTFZrixS+eOIyqK8L89Dze85NSTr4EcwqXulYF6A== X-Received: by 2002:a7b:c413:0:b0:3ff:ca80:eda3 with SMTP id k19-20020a7bc413000000b003ffca80eda3mr7191670wmi.10.1693036868537; Sat, 26 Aug 2023 01:01:08 -0700 (PDT) Received: from localhost (cst2-173-16.cust.vodafone.cz. [31.30.173.16]) by smtp.gmail.com with ESMTPSA id 16-20020a05600c229000b003fff96bb62csm4253440wmf.16.2023.08.26.01.01.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Aug 2023 01:01:07 -0700 (PDT) Date: Sat, 26 Aug 2023 10:01:06 +0200 From: Andrew Jones To: Evan Green Cc: Conor Dooley , Conor Dooley , Anup Patel , Albert Ou , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Palmer Dabbelt , Palmer Dabbelt , Bagas Sanjaya , Paul Walmsley , linux-riscv@lists.infradead.org, Heiko Stuebner Subject: Re: [PATCH v4] RISC-V: Show accurate per-hart isa in /proc/cpuinfo Message-ID: <20230826-3869468d499caf2850681d08@orel> References: <20230711201831.2695097-1-evan@rivosinc.com> <20230824-factual-jawed-2dddd2cf2bdd@wendy> <20230824-exploit-spectacle-ecedd91e9075@spud> <20230825-374a82446ed3eea02fcb41e6@orel> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Aug 25, 2023 at 03:51:28PM -0700, Evan Green wrote: > On Fri, Aug 25, 2023 at 1:16 AM Andrew Jones wrote: > > > > On Thu, Aug 24, 2023 at 03:06:53PM -0700, Evan Green wrote: > > > On Thu, Aug 24, 2023 at 10:29 AM Conor Dooley wrote: > > ... > > > > Do you want to have this new thing in cpuinfo tell the user "this hart > > > > has xyz extensions that are supported by a kernel, but maybe not this > > > > kernel" or to tell the user "this hart has xyz extensions that are > > > > supported by this kernel"? Your text above says "understood by the > > > > kernel", but I think that's a poor definition that needs to be improved > > > > to spell out exactly what you mean. IOW does "understood" mean the > > > > kernel will parse them into a structure, or does it mean "yes you can > > > > use this extension on this particular hart". > > > > > > I'm imagining /proc/cpuinfo being closer to "the CPU has it and the > > > kernel at least vaguely understands it, but may not have full support > > > for it enabled". I'm assuming /proc/cpuinfo is mostly used by 1) > > > humans wanting to know if they have hardware support for a feature, > > > and 2) administrators collecting telemetry to manage fleets (ie do I > > > have any hardware deployed that supports X). > > > > Is (2) a special case of (1)? (I want to make sure I understand all the > > cases.) > > More or less, yes. In bucket two are also folks wondering things like > "are all these crash reports I'm getting specific to machines with X". > > > > > > Programmers looking to > > > see "is the kernel support for this feature ready right now" would > > > ideally not be parsing /proc/cpuinfo text, as more direct mechanisms > > > like specific hwprobe bits for "am I fully ready to go" would be > > > easier to work with. Feel free to yell at me if this overall vision > > > seems flawed. > > > > > > I tried to look to see if there was consensus among the other > > > architectures. Aarch64 seems to go with "supported and fully enabled", > > > as their cpu_has_feature() directly tests elf_hwcap, and elements in > > > arm64_elf_hwcaps[] are Kconfig gated. X86 is complicated, but IIRC is > > > more along the lines of "hardware has it". They have two macros, > > > cpu_has() for "raw capability" and cpu_feature_enabled() for "kernel > > > can do it too", and they use cpu_has() for /proc/cpuinfo flags. > > > > > > > I'd lean more towards the way AArch64 goes, because, unless /proc/cpuinfo > > is just a blind regurgitation of an isa string from DT / ACPI, then the > > kernel must at least know something about it. Advertising a feature which > > is known, but also known not to work, seems odd to me. So my vote is that > > only features which are present and enabled in the kernel or present and > > not necessary to be enabled in the kernel in order for userspace or > > virtual machines to use be advertised in /proc/cpuinfo. > > > > We still have SMBIOS (dmidecode) to blindly dump what the hardware > > supports for cases (1) and (2) above. > > Yeah, there's an argument to be made for that. My worry is it's a > difficult line to hold. The bar you're really trying to describe (or > at least what people might take away from it) is "if it's listed here > then it's fully ready to be used in userspace". But then things get > squishy when there are additional ways to control the use of the > feature (prctls() in init to turn it on, usermode policy to turn it > off, security doodads that disable it, etc). I'm assuming nobody wants > a version of /proc/cpuinfo that changes depending on which process is > asking. So then the line would have to be more carefully described as > "well, the hardware can do it, and the kernel COULD do it under some > circumstances, but YMMV", which ends up falling somewhat short of the > original goal. In my mind keeping /proc/cpuinfo as close to "here's > what the hardware can do" seems like a more defensible position. > -Evan I agree with that. I was actually even trying to say the same thing, but only by bringing up virtual machines. Once we decide we'll expose extensions to VMs, whether or not the host kernel enables them, then none of the other host kernel configurations matter with respect to advertising the feature, since the guest kernel may have a completely different set of configurations. So I think we should only be filtering out extensions that are disabled because they're broken (have a detected erratum), have been "hidden" (have a kernel command line allowing them to be treated as if not present), or cannot be used at all due to missing accompanying hardware descriptions (such as block size info for CBO extensions). In all cases, I presume we'd wire checks up in riscv_isa_extension_check() and no checks would be gated on Kconfigs or anything else. And, since /proc/cpuinfo gets its list from the bitmap that's already filtered by riscv_isa_extension_check(), then, long story short, we're good to go :-) But maybe we can try to spell that policy out a bit more in Documentation/riscv/uabi.rst. Thanks, drew