From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost.localdomain (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F2FAB385843A for ; Wed, 17 Aug 2022 00:49:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E70973858C2D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSW.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca X-Authority-Analysis: v=2.4 cv=a6MjSGeF c=1 sm=1 tr=0 ts=62fc3b17 a=oHm12aVswOWz6TMtn9zYKg==:117 a=oHm12aVswOWz6TMtn9zYKg==:17 a=5_s1rtZIAAAA:8 a=ktCM2HRfdLbtuaHhBGgA:9 a=7-3sKM-zqIYA:10 a=3dMv4P1n_z9a81GE33Fp:22 From: "Cygwin cpuid Maintainer" To: cygwin@cygwin.com Date: Tue, 16 Aug 2022 18:48:22 -0600 Message-Id: Subject: [ANNOUNCEMENT] Fixed: cpuid 20220812-2 X-CMAE-Envelope: MS4xfN9MbQnFwWNNoIDIX13e5KwMTw+jWujKjpJtTQiNMR8l6eeLJBOV+dVZGOav1SUhr9G87um/cFH44gDoljK5BwHHY/JGwdZrWHuaali6pnEzaL6uy84J c1Seq+/7JTfs/pju1AZaGSi0W0fvf9QMB++yIGKkD1+emnyfkhulo5kvXK5nq2h0QrkcUO8AM26ZoHDoQ9CsX6fmWxYFOnj0Z20P5o0H6E5+uuU2isV47eCd X-Spam-Status: No, score=-1163.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin-announce@cygwin.com X-Mailman-Version: 2.1.29 Reply-To: cygwin@cygwin.com Errors-To: cygwin-announce-bounces+cygwin-announce-resender=cygwin.com@cygwin.com X-Mailer: Perl5 Mail::Internet v2.20 Sender: Kernel Overflow User X-BeenThere: cygwin@cygwin.com Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 00:49:58 -0000 The following package has been fixed in the Cygwin distribution: * cpuid 20220812-2 This Cygwin re-release corrects an issue with the previous Cygwin release 20220812-1, which failed to correctly detect the number of CPUs and resulted in no output. The current release has been patched and the patch submitted upstream as a suggested fix. The Cygwin build process has had tests added, which will hopefully prevent any recurrence, and those have been suggested to upstream as a possible enhancement. 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.