[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cygwin-patches
Subject:    Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags
From:       Corinna Vinschen <corinna-cygwin () cygwin ! com>
Date:       2024-03-18 22:40:11
Message-ID: ZfjCy8bDdq3ID6cM () calimero ! vinschen ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]