public inbox for cygwin-announce@cygwin.com
 help / color / mirror / Atom feed
From: "Cygwin cpuid Maintainer" <Brian.Inglis@SystematicSW.ab.ca>
To: "Cygwin Announcements" <cygwin-announce@cygwin.com>
Subject: Updated: cpuid 20220812
Date: Mon, 15 Aug 2022 00:41:00 -0600	[thread overview]
Message-ID: <20220815004100.45303-1-Brian.Inglis@SystematicSW.ab.ca> (raw)

The following package has been upgraded in the Cygwin distribution:

* cpuid		20220812

The program displays detailed information about the CPU(s) gathered from
the CPUID instruction, and also determines the exact model of CPU(s).

Whereas /proc/cpuinfo is like an abstract of the features important to
Linux in a system, cpuid is a standalone utility which writes a paper
expounding on every feature in each CPU's architecture and what it can
do, at about the one line per bit level.

It is updated and released frequently to stay current with Intel and
AMD information and supports other vendors' chips.

See the project home page for more information:

	http://etallen.com/cpuid.html

For information about changes since the previous Cygwin release,
see below or /usr/share/doc/cpuid/ChangeLog after installation.


Fri Aug 12 2022		20220812

* Corrected (synth) decoding for (0,6),(8,6) Intel Snow
  Ridge/Parker Ridge.  It had been lumped in with Elkhart Lake, but only
  because that had been the only known core name for the Tremont uarch.
  These appear to be different cores.  Also added steppings from SSG*.
* Added 8000000a/edx X2AVIC flag, from Linux kernel patches
  It appears to be undocumented, so far.
* Improved (synth) decoding for (0,6),(9,7),2, adding Alder Lake-HX.
* Reverted May 27 2022 split of 7/0/ebx hack to report bit 22
  as RDPID on AMD architectures. The AMD documentation is inconsistent
  on the location of this flag.  In E.3.6, it claims 7/0/ebx.  But in
  section 3, the RDPID instruction itself claims 7/0/ecx, as does the
  mention in Table 3-1. This also is consistent with Intel
  architectures.  Thanks to Stefan Kanthak for pointing this out.
* Generalized (0,6),(8,14),9,YP stepping case to include
  Pentium 4425Y, from instlatx64 sample.
* Updated 7/0/edx comments to reflect original info source
  for SRBDS mitigation MSR available, previously just marked LX*.
* Updated 7/0/edx comments to reflect original info source
  for RTM transaction always aborts, previously just marked LX*.
* Added (vuln to branch type confusion synth) synthetic leaf
  to correct for the one known inaccuracy.
* cpuid.man: Added those two original source web pages from Intel:
  Intel Transactional Synchronization Extensions (Intel TSX) Memory and
  Performance Monitoring Update for Intel Processors (Article ID
  000059422), Special Register Buffer Data Sampling.
* Added 0x80000008/ebx not vulnerable to branch type confusion
  flag from "Technical Guidance For Mitigating Branch Type Confusion
  (White Paper)".  Also added a synthetic flag to correct the special
  case for Family 0x19, where the raw flag is documented to be wrong.
* Added 7/2/edx indirect branch prediction related flags from
  Intel's "Branch History Injection and Intra-mode Branch Target
  Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598".
* Added (uarch synth) decoding for (0,6),(6,14) Cougar
  Mountain, mentioned as Airmont by Intel's "Retpoline: A Branch Target
  Injection Mitigation".
* cpuid.man: Added "Branch History Injection and Intra-mode Branch Target
  Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598" and
  "Retpoline: A Branch Target Injection Mitigation".
* Clarified (synth) for (0,6),(8,13) Tiger Lake-H from SSG*.
* Added support for hypervisor+3/ecx (Microsoft) flags.
* Added support for hypervisor+0xa/eax (Microsoft) VMCS
  GuestIa32DebugCtl support flag.
* Added support for hypervisor+0xa/ebx (Microsoft) VMCS
  HvFlushGuestPhysicalAddress* flag.
* Added (synth) for (0,6),(11,10),3 Raptor Lake-P Q0, from
  Coreboot*.
* Lionel Debroux's patch used MAX_CPUS all the time.  But it
  really was meaningful only for the USE_KERNEL_SCHED_SETAFFINITY case
  (although, by happenstance, it may have been correct for all three
  cases).  Replace this with an nr_cpu_ids global, determined by
  get_nr_cpu_ids().  The simplest version just returns
  sysconf(_SC_NPROCESSORS_CONF), although that could be problematic on
  systems with non-contiguous CPU numbers.
* For USE_KERNEL_SCHED_SETAFFINITY, improve this, and also
  support systems with > 1024 CPUs, by estimating nr_cpu_ids using a
  power-of-2 walk through successively larger cpu_set_t sizes until
  sched_getaffinity succeeds.
* For systems using cpu_set_t (only Cygwin?), cap the
  nr_cpu_ids to CPU_SETSIZE.
* The _SC_NPROCESSORS_CONF check in real_setup() is removed
  because it's redundant now.
* In do_real() and do_real_one(), avoid breaking out of loop
  because of downed CPUs.


                 reply	other threads:[~2022-08-15  6:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220815004100.45303-1-Brian.Inglis@SystematicSW.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin-announce@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).