[PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Brian Inglis]

add Linux 6.8 cpuinfo flags:
Intel 0x00000007:1 eax:17 fred		Flexible Return and Event Delivery;
AMD   0x8000001f   eax:4  sev_snp	SEV secure nested paging;
document unused and some unprinted bits that could look like omissions;
fix typos and misalignments;

Signed-off-by: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
---
 winsup/cygwin/fhandler/proc.cc | 38 +++++++++++++++++++++++++++-------
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/winsup/cygwin/fhandler/proc.cc b/winsup/cygwin/fhandler/proc.cc
index be107cb8eacc..cb754185b833 100644
--- a/winsup/cygwin/fhandler/proc.cc
+++ b/winsup/cygwin/fhandler/proc.cc
@@ -1233,6 +1233,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
       ftcprint (features2, 13, "cx16");     /* cmpxchg16b instruction */
       ftcprint (features2, 14, "xtpr");     /* send task priority messages */
       ftcprint (features2, 15, "pdcm");     /* perf/debug capabilities MSR */
+/*    ftcprint (features2, 16, "");     */  /* unused */
       ftcprint (features2, 17, "pcid");     /* process context identifiers */
       ftcprint (features2, 18, "dca");      /* direct cache access */
       ftcprint (features2, 19, "sse4_1");   /* xmm 4_1 sse 4.1 */
@@ -1273,14 +1274,18 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	      ftcprint (features1, 11, "xop");		/* sse 5 extended AVX */
 	      ftcprint (features1, 12, "skinit");       /* skinit/stgi */
 	      ftcprint (features1, 13, "wdt");          /* watchdog timer */
+/*	      ftcprint (features1, 14, ""); */		/* unused */
 	      ftcprint (features1, 15, "lwp");          /* light weight prof */
 	      ftcprint (features1, 16, "fma4");         /* 4 operand MAC */
 	      ftcprint (features1, 17, "tce");          /* translat cache ext */
+/*	      ftcprint (features1, 18, ""); */		/* unused */
 	      ftcprint (features1, 19, "nodeid_msr");   /* nodeid MSR */
+/*	      ftcprint (features1, 20, ""); */		/* unused */
 	      ftcprint (features1, 21, "tbm");          /* trailing bit manip */
 	      ftcprint (features1, 22, "topoext");      /* topology ext */
 	      ftcprint (features1, 23, "perfctr_core"); /* core perf ctr ext */
 	      ftcprint (features1, 24, "perfctr_nb");   /* NB perf ctr ext */
+/*	      ftcprint (features1, 25, ""); */		/* unused */
 	      ftcprint (features1, 26, "bpext");        /* data brkpt ext */
 	      ftcprint (features1, 27, "ptsc");         /* perf timestamp ctr */
 	      ftcprint (features1, 28, "perfctr_llc");  /* ll cache perf ctr */
@@ -1447,6 +1452,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1, 19, "adx");          /* adcx/adox */
 	  ftcprint (features1, 20, "smap");         /* sec mode access prev */
 	  ftcprint (features1, 21, "avx512ifma");   /* vec int FMA */
+/*	  ftcprint (features1, 22, ""); */	    /* unused */
 	  ftcprint (features1, 23, "clflushopt");   /* cache line flush opt */
 	  ftcprint (features1, 24, "clwb");         /* cache line write back */
 	  ftcprint (features1, 25, "intel_pt");     /* intel processor trace */
@@ -1468,6 +1474,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1,  1, "xsavec");   /* xsavec instruction */
 	  ftcprint (features1,  2, "xgetbv1");  /* xgetbv ecx 1 */
 	  ftcprint (features1,  3, "xsaves");   /* xsaves/xrstors */
+/*	  ftcprint (features1,  4, "xfd"); */	/* eXtended Feature Disabling */
 	}
       /* cpuid 0x0000000f edx */
       if (maxf >= 0x0000000f)
@@ -1502,9 +1509,18 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1,  4, "avx_vnni");	    /* vex enc NN vec */
 	  ftcprint (features1,  5, "avx512_bf16");  /* vec bfloat16 short */
 /*	  ftcprint (features1,  7, "cmpccxadd"); */ /* CMPccXADD instructions */
-/*	  ftcprint (features1, 18, "lkgs");	 */ /* load kernel (userspace) GS */
-/*	  ftcprint (features1, 21, "amx_fp16");	 */ /* AMX fp16 Support */
-/*	  ftcprint (features1, 23, "avx_ifma");	 */ /* Support for VPMADD52[H,L]UQ */
+/*	  ftcprint (features1,  8, "arch_perf"); */ /* Arch PerfMon Extension */
+/*	  ftcprint (features1, 10, "fzrm");	*/  /* Fast zero-length REP MOVSB */
+/*	  ftcprint (features1, 11, "fsrs");	*/  /* Fast short REP STOSB    */
+/*	  ftcprint (features1, 12, "fsrc");	*/  /* Fast short REP {CMPSB,SCASB} */
+	  ftcprint (features1, 17, "fred");	    /* Flexible Return and Event Delivery */
+/*	  ftcprint (features1, 18, "lkgs");	*/  /* load kernel (userspace) GS */
+/*	  ftcprint (features1, 19, "wrmsrns");	*/  /* Non-serializing WRMSR */
+/*	  ftcprint (features1, 21, "amx_fp16");	*/  /* AMX fp16 Support	*/
+/*	  ftcprint (features1, 22, "amx_bf16");	*/  /* AMX bf16 Support */
+/*	  ftcprint (features1, 23, "avx_ifma");	*/  /* Support for VPMADD52[H,L]UQ */
+/*	  ftcprint (features1, 24, "amx_tile");	*/  /* AMX tile Support */
+/*	  ftcprint (features1, 25, "amx_int8");	*/  /* AMX int8 Support */
 	  ftcprint (features1, 26, "lam");	    /* Linear Address Masking */
 	}
 
@@ -1531,6 +1547,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 /*	  ftcprint (features1, 26, "ssb_no"); */    /* ssb fixed in hardware */
 	  ftcprint (features1, 27, "cppc");	    /* collab proc perf ctl */
 /*	  ftcprint (features1, 28, "amd_psfd"); */  /* predictive store fwd dis */
+/*	  ftcprint (features1, 29, "btc_no"); */    /* Not vulnerable to Branch Type Confusion */
 	  ftcprint (features1, 31, "brs");	    /* branch sampling */
         }
 
@@ -1564,7 +1581,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1,  4, "tsc_scale");        /* TSC rate control */
 	  ftcprint (features1,  5, "vmcb_clean");       /* VMCB clean bits */
 	  ftcprint (features1,  6, "flushbyasid");      /* flush by ASID */
-	  ftcprint (features1,  7, "decode_assists");   /* decode assists */
+	  ftcprint (features1,  7, "decodeassists");	/* decode assists */
 	  ftcprint (features1, 10, "pausefilter");      /* filt pause intrcpt */
 	  ftcprint (features1, 12, "pfthreshold");      /* pause filt thresh */
 	  ftcprint (features1, 13, "avic");             /* virt int control */
@@ -1580,6 +1597,7 @@ format_proc_cpuinfo (void *, char *&destbuf)
         {
 	  cpuid (&unused, &unused, &features1, &unused, 0x00000007, 0);
 
+/*	  ftcprint (features1,  0, ""); */		/* unused */
 	  ftcprint (features1,  1, "avx512vbmi");	/* vec bit manip */
 	  ftcprint (features1,  2, "umip");             /* user mode ins prot */
 	  ftcprint (features1,  3, "pku");              /* prot key userspace */
@@ -1594,10 +1612,14 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features1, 12, "avx512_bitalg");    /* vpopcnt/b/w vpshuf */
 	  ftcprint (features1, 13, "tme");              /* total mem encrypt */
 	  ftcprint (features1, 14, "avx512_vpopcntdq"); /* vec popcnt dw/qw */
+/*	  ftcprint (features1, 15, ""); */		/* unused */
 	  ftcprint (features1, 16, "la57");             /* 5 level paging */
+/*	  ftcprint (features1, .., ""); */		/* unused */
 	  ftcprint (features1, 22, "rdpid");            /* rdpid instruction */
+/*	  ftcprint (features1, 23, ""); */		/* unused */
 	  ftcprint (features1, 24, "bus_lock_detect");	/* bus lock detect dbg excptn */
 	  ftcprint (features1, 25, "cldemote");         /* cldemote instr */
+/*	  ftcprint (features1, 26, ""); */		/* unused */
 	  ftcprint (features1, 27, "movdiri");          /* movdiri instr */
 	  ftcprint (features1, 28, "movdir64b");        /* movdir64b instr */
 	  ftcprint (features1, 29, "enqcmd");		/* enqcmd/s instructions*/
@@ -1610,8 +1632,9 @@ format_proc_cpuinfo (void *, char *&destbuf)
           cpuid (&unused, &features1, &unused, &unused, 0x80000007, 0);
 
           ftcprint (features1,  0, "overflow_recov");	/* MCA oflow recovery */
-          ftcprint (features1,  1, "succor");           /* uncor err recovery */
-          ftcprint (features1,  3, "smca");             /* scalable MCA */
+          ftcprint (features1,  1, "succor");		/* uncor err recovery */
+/*        ftcprint (features1,  2, ""); */		/* unused */
+          ftcprint (features1,  3, "smca");		/* scalable MCA */
         }
 
       /* Intel cpuid 0x00000007 edx */
@@ -1646,8 +1669,9 @@ format_proc_cpuinfo (void *, char *&destbuf)
 	  ftcprint (features2,  1, "sev");	/* AMD secure encrypted virt */
 /*	  ftcprint (features2,  2, "vm_page_flush");*/	/* VM page flush MSR */
 	  ftcprint (features2,  3, "sev_es");	/* AMD SEV encrypted state */
-/*	  ftcprint (features2,  4, "sev_snp");*//* AMD SEV secure nested paging */
+	  ftcprint (features2,  4, "sev_snp");	/* AMD SEV secure nested paging */
 /*	  ftcprint (features2,  5, "vmpl");   *//* VM permission levels support */
+/*	  ftcprint (features2,  9, "v_tsc_aux"); */	/* Virtual TSC_AUX */
 /*	  ftcprint (features2, 10, "sme_coherent");   *//* SME h/w cache coherent */
 /*	  ftcprint (features2, 11, "sev_64b");*//* SEV 64 bit host guest only */
 /*	  ftcprint (features2, 12, "sev_rest_inj");   *//* SEV restricted injection */
-- 
2.43.0

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Corinna Vinschen]

Hi Brian,

On Mar 16 10:44, Brian Inglis wrote:
> add Linux 6.8 cpuinfo flags:
> Intel 0x00000007:1 eax:17 fred		Flexible Return and Event Delivery;
> AMD   0x8000001f   eax:4  sev_snp	SEV secure nested paging;
> document unused and some unprinted bits that could look like omissions;
> fix typos and misalignments;

I'm a bit puzzled about the "unused" slots.  You're adding them
only in some places.  What makes them "look like omissions"?


Thanks,
Corinna

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Brian Inglis]

On 2024-03-18 03:33, Corinna Vinschen wrote:
> Hi Brian,
> 
> On Mar 16 10:44, Brian Inglis wrote:
>> add Linux 6.8 cpuinfo flags:
>> Intel 0x00000007:1 eax:17 fred		Flexible Return and Event Delivery;
>> AMD   0x8000001f   eax:4  sev_snp	SEV secure nested paging;
>> document unused and some unprinted bits that could look like omissions;
>> fix typos and misalignments;
> 
> I'm a bit puzzled about the "unused" slots.  You're adding them
> only in some places.  What makes them "look like omissions"?

Mainly because single bits are omitted, presumably because they do not want to 
pollute the symbol space with as yet unused features, just as they do not output 
all features as cpuinfo flags, until it indicates something about the build 
and/or system.

Compare the minimal common standard feature bits defined in the gcc lib cpuid.h 
and gcc cpuinfo.h headers, with Linux cpuinfo cpufeatures.h, and the output of 
the cpuid utility, where almost all bits in older cpuid entries are defined.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Corinna Vinschen]

On Mar 18 08:10, Brian Inglis wrote:
> On 2024-03-18 03:33, Corinna Vinschen wrote:
> > Hi Brian,
> > 
> > On Mar 16 10:44, Brian Inglis wrote:
> > > add Linux 6.8 cpuinfo flags:
> > > Intel 0x00000007:1 eax:17 fred		Flexible Return and Event Delivery;
> > > AMD   0x8000001f   eax:4  sev_snp	SEV secure nested paging;
> > > document unused and some unprinted bits that could look like omissions;
> > > fix typos and misalignments;
> > 
> > I'm a bit puzzled about the "unused" slots.  You're adding them
> > only in some places.  What makes them "look like omissions"?
> 
> Mainly because single bits are omitted, presumably because they do not want
> to pollute the symbol space with as yet unused features, just as they do not
> output all features as cpuinfo flags, until it indicates something about the
> build and/or system.
> 
> Compare the minimal common standard feature bits defined in the gcc lib
> cpuid.h and gcc cpuinfo.h headers, with Linux cpuinfo cpufeatures.h, and the
> output of the cpuid utility, where almost all bits in older cpuid entries
> are defined.

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.


Thanks,
Corinna

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Brian Inglis]

On 2024-03-18 09:45, Corinna Vinschen wrote:
> On Mar 18 08:10, Brian Inglis wrote:
>> On 2024-03-18 03:33, Corinna Vinschen wrote:
>>> On Mar 16 10:44, Brian Inglis wrote:
>>>> add Linux 6.8 cpuinfo flags:
>>>> Intel 0x00000007:1 eax:17 fred		Flexible Return and Event Delivery;
>>>> AMD   0x8000001f   eax:4  sev_snp	SEV secure nested paging;
>>>> document unused and some unprinted bits that could look like omissions;
>>>> fix typos and misalignments;
>>>
>>> I'm a bit puzzled about the "unused" slots.  You're adding them
>>> only in some places.  What makes them "look like omissions"?
>>
>> Mainly because single bits are omitted, presumably because they do not want
>> to pollute the symbol space with as yet unused features, just as they do not
>> output all features as cpuinfo flags, until it indicates something about the
>> build and/or system.
>>
>> Compare the minimal common standard feature bits defined in the gcc lib
>> cpuid.h and gcc cpuinfo.h headers, with Linux cpuinfo cpufeatures.h, and the
>> output of the cpuid utility, where almost all bits in older cpuid entries
>> are defined.
> 
> 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.

$ grep -iC1 'avx512ifma\|clflushopt\|xsaves\|xfd' *
capflags.h-     [X86_FEATURE_SMAP]               = "smap",
capflags.h:     [X86_FEATURE_AVX512IFMA]         = "avx512ifma",
capflags.h:     [X86_FEATURE_CLFLUSHOPT]         = "clflushopt",
capflags.h-     [X86_FEATURE_CLWB]               = "clwb",
--
capflags.h-     [X86_FEATURE_XGETBV1]            = "xgetbv1",
capflags.h:     [X86_FEATURE_XSAVES]             = "xsaves",
capflags.h-     [X86_FEATURE_CQM_LLC]            = "cqm_llc",
--
cpufeatures.h-#define X86_FEATURE_SMAP          ( 9*32+20) /* Supervisor Mode 
Access Prevention */
cpufeatures.h:#define X86_FEATURE_AVX512IFMA    ( 9*32+21) /* AVX-512 Integer 
Fused Multiply-Add instructions */
cpufeatures.h:#define X86_FEATURE_CLFLUSHOPT    ( 9*32+23) /* CLFLUSHOPT 
instruction */
cpufeatures.h-#define X86_FEATURE_CLWB          ( 9*32+24) /* CLWB instruction */
--
cpufeatures.h-#define X86_FEATURE_XGETBV1       (10*32+ 2) /* XGETBV with ECX = 
1 instruction */
cpufeatures.h:#define X86_FEATURE_XSAVES        (10*32+ 3) /* XSAVES/XRSTORS 
instructions */
cpufeatures.h:#define X86_FEATURE_XFD           (10*32+ 4) /* "" eXtended 
Feature Disabling */
cpufeatures.h-
--
cpufeatures.log-Intel   0x00000007      0       EBX     20      "smap" 
        Supervisor Mode Access Prevention
cpufeatures.log:Intel   0x00000007      0       EBX     21      "avx512ifma" 
        AVX-512 Integer Fused Multiply-Add instructions
cpufeatures.log:Intel   0x00000007      0       EBX     23      "clflushopt" 
        CLFLUSHOPT instruction
cpufeatures.log-Intel   0x00000007      0       EBX     24      "clwb" 
        CLWB instruction
--
cpufeatures.log-        0x0000000d      1       EAX      2      "xgetbv1" 
        XGETBV with ECX = 1 instruction
cpufeatures.log:        0x0000000d      1       EAX      3      "xsaves" 
        XSAVES/XRSTORS instructions
cpufeatures.log:        0x0000000d      1       EAX      4      "" 
        xfd eXtended Feature Disabling

[TL:DR

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.]

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Corinna Vinschen]

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