From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id F05213858C5F; Mon, 18 Mar 2024 22:40:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F05213858C5F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1710801612; bh=n6HyCmscmVjKlpbokvWyxunxfvQzYlV3LO/9k9HjdlY=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=cvr9wMfr4xx7WV/ghO8cyFinChKgJqeSupd7WEhXAEdbkhkYqveSMt96XFC1ACJ5j +BlLUxQGJODdEdyt+kdRDgndCQNiFoChwroqp1ByjGqNGbfHL35Jy7dbam1JJZO5Dx S5uvkPw99MVhUM7mm6npw5ezPJaylVUMFpp4UPAM= Received: by calimero.vinschen.de (Postfix, from userid 500) id 3D9A2A8098F; Mon, 18 Mar 2024 23:40:11 +0100 (CET) Date: Mon, 18 Mar 2024 23:40:11 +0100 From: Corinna Vinschen To: cygwin-patches@cygwin.com Subject: Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags Message-ID: Reply-To: cygwin-patches@cygwin.com Mail-Followup-To: cygwin-patches@cygwin.com References: <86a84fad25ec3b5c49e9b737dfccbdb2f510556e.1710519553.git.Brian.Inglis@SystematicSW.ab.ca> <1ebfb5dd-f5b8-4f6c-a6aa-e1b7873d7802@systematicsw.ab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: On Mar 18 11:21, Brian Inglis wrote: > On 2024-03-18 09:45, Corinna Vinschen wrote: > > I see. I just don't understands the difference between, say, > > > > ftcprint (features1, 21, "avx512ifma"); /* vec int FMA */ > > + /* ftcprint (features1, 22, ""); */ /* unused */ > > ftcprint (features1, 23, "clflushopt"); /* cache line flush opt */ > > > > and > > > > ftcprint (features1, 3, "xsaves"); /* xsaves/xrstors */ > > + /* ftcprint (features1, 4, "xfd"); */ /* eXtended Feature Disabling */ > > > > The latter makes sense, of course, but why is the first comment "unused", > > rather than something like "PCOMMIT instruction" as in the cpuid output? > > > > Note that I'm not saying that you have to change that, but I would like > > to understand it. > > Hi Corinna, > > The cpuid output is not always up to date with the kernel, and there are a > lot of bits defined, so if Linux does not use the bit I will not mention it, > except where uses and visibility may vary because of merge/patch revisions, > as happened recently with shstk and lam handling changes. > > The cpuinfo capflags are generated by running the Linux build script > mkcapflags.sh, from the feature symbol suffix, unless overriden by a quoted > string at the start of the comment, and "" suppresses cpuinfo flag output. > > In my weekly pulls of relevant rc sources, I generate a couple of summary > logs to merge the cpuinfo capflags with the comments and feature bits, and > diff everything relevant vs the previous tagged release. > > I keep an eye on those diffs, and when the next release is no longer a > candidate, I pull up the Linux changes and look at how they can be added to > Cygwin. > > I sometimes add features commented out to document bits used in a feature > word, but not yet displayed on cpuinfo, just to make it easier to compare > with Linux, or more obvious that an unused bit has not been missed. > The latest additions are the result of uncertainties raised during my last > cross check. > > Below is a sample of the info used to display Linux cpuinfo flags, which I > use to support Cygwin's, relevant to those you mentioned. > Linux feature word 9 bit 22 is unused, and word 10 bit 4 is not displayed. > [...] > Many of the synthetic Linux features and flags are derived from hw boot or > MSR info, which we can not yet access from Cygwin, so I ignore those > changes, unless the feature can be derived from information readily > available as a user in the cpu, Windows, or Cygwin. > > I cross check the Linux and Cygwin sources occasionally to ensure I have not > missed anything added or removed, spelling changes, Linux tweaks, or > readability. > > I have so far ignored feature disabling depending on conditions, and cpu > errata checks and output, as some of that requires MSR info or low level > access. > > I have looked at trying to extract or generate tables from the Linux sources > to drive our cpuinfo, use gcc cpuid and cpuinfo headers, automate or at > least simplify maintenance, but there are many exceptions which we can not > determine to output, and Intel's practices are not as architecturally > structured as AMD's, so require code to decide.] Thanks for the explanation. Pushed. Corinna