* Compatibility issues around <sys/platform/x86.h> @ 2020-12-21 13:00 Florian Weimer 2020-12-21 17:05 ` H.J. Lu 0 siblings, 1 reply; 8+ messages in thread From: Florian Weimer @ 2020-12-21 13:00 UTC (permalink / raw) To: libc-alpha I finally had some time to review the <sys/platform/x86.h> interface. I have two major concerns: (a) Placement of struct cpu_features in _rtld_global_ro This means that backporting new feature support changes the internal GLIBC_PRIVATE ABI. Consequently, there's a race condition during in-place updates where loading binaries can fail in obscure ways, due to the change in _rtld_global_ro offsets. We should really avoid this. (c) The COMMON_CPUID_INDEX_MAX handshake does not work. __x86_get_cpu_features returns NULL if its argument is too large. This effectively disables *all* feature bits, not just those beyond COMMON_CPUID_INDEX_MAX. This means that if you build with a header that is too new, an application may fail due to the lack of detected features when running on an older glibc version. Ideally, only the newly added CPU features would be detected as missing in this scenario. Simply recompiling an application with a newer header should not result in any detection changes. Not quite a major concern is that this feature is not usable from IFUNC resolvers with BIND_NOW, which I consider an important use of CPU feature selection. I do not have a good solution here that can be implemented in time for glibc 2.33. I expect that a proper solution will require some binutils work. I'm going to work on this with priority this week and hope to have patches posted by the 24th. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-21 13:00 Compatibility issues around <sys/platform/x86.h> Florian Weimer @ 2020-12-21 17:05 ` H.J. Lu 2020-12-21 17:15 ` Adhemerval Zanella ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: H.J. Lu @ 2020-12-21 17:05 UTC (permalink / raw) To: Florian Weimer; +Cc: GNU C Library On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: > > I finally had some time to review the <sys/platform/x86.h> interface. > > I have two major concerns: > > (a) Placement of struct cpu_features in _rtld_global_ro > > This means that backporting new feature support changes the internal > GLIBC_PRIVATE ABI. Consequently, there's a race condition during > in-place updates where loading binaries can fail in obscure ways, due to > the change in _rtld_global_ro offsets. We should really avoid this. This applies to all members in _rtld_global_ro. > (c) The COMMON_CPUID_INDEX_MAX handshake does not work. > > __x86_get_cpu_features returns NULL if its argument is too large. This > effectively disables *all* feature bits, not just those beyond > COMMON_CPUID_INDEX_MAX. This means that if you build with a header that Can you open a glibc bug? It shouldn't be too hard to fix. I can take a look if you don't have time. > is too new, an application may fail due to the lack of detected features > when running on an older glibc version. Ideally, only the newly added > CPU features would be detected as missing in this scenario. Simply > recompiling an application with a newer header should not result in any > detection changes. > > > Not quite a major concern is that this feature is not usable from IFUNC > resolvers with BIND_NOW, which I consider an important use of CPU > feature selection. I do not have a good solution here that can be > implemented in time for glibc 2.33. I expect that a proper solution > will require some binutils work. Can you open a glibc bug? > I'm going to work on this with priority this week and hope to have > patches posted by the 24th. > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill > -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-21 17:05 ` H.J. Lu @ 2020-12-21 17:15 ` Adhemerval Zanella 2020-12-22 11:42 ` H.J. Lu 2020-12-22 11:42 ` H.J. Lu 2020-12-22 13:32 ` Florian Weimer 2 siblings, 1 reply; 8+ messages in thread From: Adhemerval Zanella @ 2020-12-21 17:15 UTC (permalink / raw) To: libc-alpha On 21/12/2020 14:05, H.J. Lu via Libc-alpha wrote: > On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: >> >> I finally had some time to review the <sys/platform/x86.h> interface. >> >> I have two major concerns: >> >> (a) Placement of struct cpu_features in _rtld_global_ro >> >> This means that backporting new feature support changes the internal >> GLIBC_PRIVATE ABI. Consequently, there's a race condition during >> in-place updates where loading binaries can fail in obscure ways, due to >> the change in _rtld_global_ro offsets. We should really avoid this. > > This applies to all members in _rtld_global_ro. Couldn't it be mitigated by adding member solely at the end of the struct and making sure the backport uses the same offset? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-21 17:15 ` Adhemerval Zanella @ 2020-12-22 11:42 ` H.J. Lu 2020-12-22 12:43 ` Adhemerval Zanella 0 siblings, 1 reply; 8+ messages in thread From: H.J. Lu @ 2020-12-22 11:42 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: GNU C Library On Mon, Dec 21, 2020 at 9:16 AM Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> wrote: > > > > On 21/12/2020 14:05, H.J. Lu via Libc-alpha wrote: > > On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: > >> > >> I finally had some time to review the <sys/platform/x86.h> interface. > >> > >> I have two major concerns: > >> > >> (a) Placement of struct cpu_features in _rtld_global_ro > >> > >> This means that backporting new feature support changes the internal > >> GLIBC_PRIVATE ABI. Consequently, there's a race condition during > >> in-place updates where loading binaries can fail in obscure ways, due to > >> the change in _rtld_global_ro offsets. We should really avoid this. > > > > This applies to all members in _rtld_global_ro. > > Couldn't it be mitigated by adding member solely at the end of the struct > and making sure the backport uses the same offset? What if we need to extend a member in the middle? -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-22 11:42 ` H.J. Lu @ 2020-12-22 12:43 ` Adhemerval Zanella 2020-12-22 12:57 ` H.J. Lu 0 siblings, 1 reply; 8+ messages in thread From: Adhemerval Zanella @ 2020-12-22 12:43 UTC (permalink / raw) To: H.J. Lu; +Cc: GNU C Library On 22/12/2020 08:42, H.J. Lu wrote: > On Mon, Dec 21, 2020 at 9:16 AM Adhemerval Zanella via Libc-alpha > <libc-alpha@sourceware.org> wrote: >> >> >> >> On 21/12/2020 14:05, H.J. Lu via Libc-alpha wrote: >>> On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: >>>> >>>> I finally had some time to review the <sys/platform/x86.h> interface. >>>> >>>> I have two major concerns: >>>> >>>> (a) Placement of struct cpu_features in _rtld_global_ro >>>> >>>> This means that backporting new feature support changes the internal >>>> GLIBC_PRIVATE ABI. Consequently, there's a race condition during >>>> in-place updates where loading binaries can fail in obscure ways, due to >>>> the change in _rtld_global_ro offsets. We should really avoid this. >>> >>> This applies to all members in _rtld_global_ro. >> >> Couldn't it be mitigated by adding member solely at the end of the struct >> and making sure the backport uses the same offset? > > What if we need to extend a member in the middle? > My question also extends if we would need to do so. Do we plan to extend the cpu_features indefinitely or can we pre-allocate a large space now for future extensions? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-22 12:43 ` Adhemerval Zanella @ 2020-12-22 12:57 ` H.J. Lu 0 siblings, 0 replies; 8+ messages in thread From: H.J. Lu @ 2020-12-22 12:57 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: GNU C Library On Tue, Dec 22, 2020 at 4:43 AM Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > > > > On 22/12/2020 08:42, H.J. Lu wrote: > > On Mon, Dec 21, 2020 at 9:16 AM Adhemerval Zanella via Libc-alpha > > <libc-alpha@sourceware.org> wrote: > >> > >> > >> > >> On 21/12/2020 14:05, H.J. Lu via Libc-alpha wrote: > >>> On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: > >>>> > >>>> I finally had some time to review the <sys/platform/x86.h> interface. > >>>> > >>>> I have two major concerns: > >>>> > >>>> (a) Placement of struct cpu_features in _rtld_global_ro > >>>> > >>>> This means that backporting new feature support changes the internal > >>>> GLIBC_PRIVATE ABI. Consequently, there's a race condition during > >>>> in-place updates where loading binaries can fail in obscure ways, due to > >>>> the change in _rtld_global_ro offsets. We should really avoid this. > >>> > >>> This applies to all members in _rtld_global_ro. > >> > >> Couldn't it be mitigated by adding member solely at the end of the struct > >> and making sure the backport uses the same offset? > > > > What if we need to extend a member in the middle? > > > > My question also extends if we would need to do so. Do we plan to extend > the cpu_features indefinitely or can we pre-allocate a large space now > for future extensions? cpu_features will grow a bit. But I don't know by how much. -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-21 17:05 ` H.J. Lu 2020-12-21 17:15 ` Adhemerval Zanella @ 2020-12-22 11:42 ` H.J. Lu 2020-12-22 13:32 ` Florian Weimer 2 siblings, 0 replies; 8+ messages in thread From: H.J. Lu @ 2020-12-22 11:42 UTC (permalink / raw) To: Florian Weimer; +Cc: GNU C Library On Mon, Dec 21, 2020 at 9:05 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: > > > > I finally had some time to review the <sys/platform/x86.h> interface. > > > > I have two major concerns: > > > > (a) Placement of struct cpu_features in _rtld_global_ro > > > > This means that backporting new feature support changes the internal > > GLIBC_PRIVATE ABI. Consequently, there's a race condition during > > in-place updates where loading binaries can fail in obscure ways, due to > > the change in _rtld_global_ro offsets. We should really avoid this. > > This applies to all members in _rtld_global_ro. > > > (c) The COMMON_CPUID_INDEX_MAX handshake does not work. > > > > __x86_get_cpu_features returns NULL if its argument is too large. This > > effectively disables *all* feature bits, not just those beyond > > COMMON_CPUID_INDEX_MAX. This means that if you build with a header that > > Can you open a glibc bug? It shouldn't be too hard to fix. I can take > a look if you don't have time. https://sourceware.org/bugzilla/show_bug.cgi?id=27104 A patch is posted at https://sourceware.org/pipermail/libc-alpha/2020-December/120968.html > > is too new, an application may fail due to the lack of detected features > > when running on an older glibc version. Ideally, only the newly added > > CPU features would be detected as missing in this scenario. Simply > > recompiling an application with a newer header should not result in any > > detection changes. > > > > > > Not quite a major concern is that this feature is not usable from IFUNC > > resolvers with BIND_NOW, which I consider an important use of CPU > > feature selection. I do not have a good solution here that can be > > implemented in time for glibc 2.33. I expect that a proper solution > > will require some binutils work. > > Can you open a glibc bug? > > > I'm going to work on this with priority this week and hope to have > > patches posted by the 24th. > > > > Thanks, > > Florian > > -- > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill > > > > > -- > H.J. -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Compatibility issues around <sys/platform/x86.h> 2020-12-21 17:05 ` H.J. Lu 2020-12-21 17:15 ` Adhemerval Zanella 2020-12-22 11:42 ` H.J. Lu @ 2020-12-22 13:32 ` Florian Weimer 2 siblings, 0 replies; 8+ messages in thread From: Florian Weimer @ 2020-12-22 13:32 UTC (permalink / raw) To: H.J. Lu via Libc-alpha [-- Attachment #1: Type: text/plain, Size: 1698 bytes --] * H. J. Lu via Libc-alpha: > On Mon, Dec 21, 2020 at 5:00 AM Florian Weimer <fweimer@redhat.com> wrote: >> >> I finally had some time to review the <sys/platform/x86.h> interface. >> >> I have two major concerns: >> >> (a) Placement of struct cpu_features in _rtld_global_ro >> >> This means that backporting new feature support changes the internal >> GLIBC_PRIVATE ABI. Consequently, there's a race condition during >> in-place updates where loading binaries can fail in obscure ways, due to >> the change in _rtld_global_ro offsets. We should really avoid this. > > This applies to all members in _rtld_global_ro. Correct, it's always a trade-off backporting something that changes the offsets. We can avoid this by using an indirection. I'd also like to avoid reliance on the preprocessor and switch to a compressed bit array, without a function call. This will allow automation of binding generation for other languages, and eventually a special relocation could be used to initialize the pointer and length early. The last part would enable use in IFUNC selectors. I've attached a draft version of the installed header (obviously untested). For the time being and uses in libc.so.6, we can generalize the existing _dl_var_init mechanism, but apply this before relocation, right after we recognize that we have loaded libc.so.6 in _dl_map_object_from_fd. Something like this is also needed to fix bug 20802. I'm slightly behind with implementing this, though. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill [-- Attachment #2: x86.h --] [-- Type: text/plain, Size: 11655 bytes --] /* Data structure for x86 CPU features. This file is part of the GNU C Library. Copyright (C) 2008-2020 Free Software Foundation, Inc. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, see <https://www.gnu.org/licenses/>. */ #ifndef _SYS_PLATFORM_X86_H #define _SYS_PLATFORM_X86_H /* Access to detected CPU features. */ extern const struct x86_cpu_array { /* Pointer to an array of __x86_count 32-bit values. */ const unsigned int *__x86_word; unsigned int __x86_count; #ifdef __LP64__ unsigned int __x86_padding; #endif } __x86_cpu_array; /* Return the word referenced by INDEX, or 0 if it is out of bounds. INDEX be one of the enumeration constants defined below, potentially ORed with 32u, to request a usable (instead of feature) CPU flag. */ static inline unsigned int __attribute__ ((const)) __x86_cpu_array_index (unsigned int __index) { if (__index >> 5 < __x86_cpu_array.__x86_count) return __x86_cpu_array.__x86_word[__index >> 5]; else return 0; } /* Return true if the CPU has feature INDEX, one of the enumeration constants defined below. */ static inline _Bool __attribute__ ((const)) x86_cpu_has_feature (unsigned int __index) { return __x86_cpu_array_index (__index) & (1u << (__index % 32)); } /* Return true if the CPU has feature INDEX, one of the enumeration constants defined below, and the feature is supported by the current executation environment. */ static inline _Bool __attribute__ ((const)) x86_cpu_is_usable (unsigned int __index) { return __x86_cpu_array_index (__index | 32u) & (1u << (__index % 32)); } enum { /* CPUID.01H:ECX. */ x86_cpu_SSE3 = 0u * 64u + 0u, x86_cpu_PCLMULQDQ = 0u * 64u + 1u, x86_cpu_DTES64 = 0u * 64u + 2u, x86_cpu_MONITOR = 0u * 64u + 3u, x86_cpu_DS_CPL = 0u * 64u + 4u, x86_cpu_VMX = 0u * 64u + 5u, x86_cpu_SMX = 0u * 64u + 6u, x86_cpu_EIST = 0u * 64u + 7u, x86_cpu_TM2 = 0u * 64u + 8u, x86_cpu_SSSE3 = 0u * 64u + 9u, x86_cpu_CNXT_ID = 0u * 64u + 10u, x86_cpu_SDBG = 0u * 64u + 11u, x86_cpu_FMA = 0u * 64u + 12u, x86_cpu_CMPXCHG16B = 0u * 64u + 13u, x86_cpu_XTPRUPDCTRL = 0u * 64u + 14u, x86_cpu_PDCM = 0u * 64u + 15u, x86_cpu_INDEX_1_ECX_16 = 0u * 64u + 16u, x86_cpu_PCID = 0u * 64u + 17u, x86_cpu_DCA = 0u * 64u + 18u, x86_cpu_SSE4_1 = 0u * 64u + 19u, x86_cpu_SSE4_2 = 0u * 64u + 20u, x86_cpu_X2APIC = 0u * 64u + 21u, x86_cpu_MOVBE = 0u * 64u + 22u, x86_cpu_POPCNT = 0u * 64u + 23u, x86_cpu_TSC_DEADLINE = 0u * 64u + 24u, x86_cpu_AES = 0u * 64u + 25u, x86_cpu_XSAVE = 0u * 64u + 26u, x86_cpu_OSXSAVE = 0u * 64u + 27u, x86_cpu_AVX = 0u * 64u + 28u, x86_cpu_F16C = 0u * 64u + 29u, x86_cpu_RDRAND = 0u * 64u + 30u, x86_cpu_INDEX_1_ECX_31 = 0u * 64u + 31u, /* CPUID.01H:EDX. */ x86_cpu_FPU = 1u * 64u + 0u, x86_cpu_VME = 1u * 64u + 1u, x86_cpu_DE = 1u * 64u + 2u, x86_cpu_PSE = 1u * 64u + 3u, x86_cpu_TSC = 1u * 64u + 4u, x86_cpu_MSR = 1u * 64u + 5u, x86_cpu_PAE = 1u * 64u + 6u, x86_cpu_MCE = 1u * 64u + 7u, x86_cpu_CX8 = 1u * 64u + 8u, x86_cpu_APIC = 1u * 64u + 9u, x86_cpu_INDEX_1_EDX_10 = 1u * 64u + 10u, x86_cpu_SEP = 1u * 64u + 11u, x86_cpu_MTRR = 1u * 64u + 12u, x86_cpu_PGE = 1u * 64u + 13u, x86_cpu_MCA = 1u * 64u + 14u, x86_cpu_CMOV = 1u * 64u + 15u, x86_cpu_PAT = 1u * 64u + 16u, x86_cpu_PSE_36 = 1u * 64u + 17u, x86_cpu_PSN = 1u * 64u + 18u, x86_cpu_CLFSH = 1u * 64u + 19u, x86_cpu_INDEX_1_EDX_20 = 1u * 64u + 20u, x86_cpu_DS = 1u * 64u + 21u, x86_cpu_ACPI = 1u * 64u + 22u, x86_cpu_MMX = 1u * 64u + 23u, x86_cpu_FXSR = 1u * 64u + 24u, x86_cpu_SSE = 1u * 64u + 25u, x86_cpu_SSE2 = 1u * 64u + 26u, x86_cpu_SS = 1u * 64u + 27u, x86_cpu_HTT = 1u * 64u + 28u, x86_cpu_TM = 1u * 64u + 29u, x86_cpu_INDEX_1_EDX_30 = 1u * 64u + 30u, x86_cpu_PBE = 1u * 64u + 31u, /* CPUID.07H.0H:EBX. */ x86_cpu_FSGSBASE = 2u * 64u + 0u, x86_cpu_TSC_ADJUST = 2u * 64u + 1u, x86_cpu_SGX = 2u * 64u + 2u, x86_cpu_BMI1 = 2u * 64u + 3u, x86_cpu_HLE = 2u * 64u + 4u, x86_cpu_AVX2 = 2u * 64u + 5u, x86_cpu_INDEX_7_EBX_6 = 2u * 64u + 6u, x86_cpu_SMEP = 2u * 64u + 7u, x86_cpu_BMI2 = 2u * 64u + 8u, x86_cpu_ERMS = 2u * 64u + 9u, x86_cpu_INVPCID = 2u * 64u + 10u, x86_cpu_RTM = 2u * 64u + 11u, x86_cpu_RDT_M = 2u * 64u + 12u, x86_cpu_DEPR_FPU_CS_DS = 2u * 64u + 13u, x86_cpu_MPX = 2u * 64u + 14u, x86_cpu_RDT_A = 2u * 64u + 15u, x86_cpu_AVX512F = 2u * 64u + 16u, x86_cpu_AVX512DQ = 2u * 64u + 17u, x86_cpu_RDSEED = 2u * 64u + 18u, x86_cpu_ADX = 2u * 64u + 19u, x86_cpu_SMAP = 2u * 64u + 20u, x86_cpu_AVX512_IFMA = 2u * 64u + 21u, x86_cpu_INDEX_7_EBX_22 = 2u * 64u + 22u, x86_cpu_CLFLUSHOPT = 2u * 64u + 23u, x86_cpu_CLWB = 2u * 64u + 24u, x86_cpu_TRACE = 2u * 64u + 25u, x86_cpu_AVX512PF = 2u * 64u + 26u, x86_cpu_AVX512ER = 2u * 64u + 27u, x86_cpu_AVX512CD = 2u * 64u + 28u, x86_cpu_SHA = 2u * 64u + 29u, x86_cpu_AVX512BW = 2u * 64u + 30u, x86_cpu_AVX512VL = 2u * 64u + 31u, /* CPUID.07H.0H:ECX. */ x86_cpu_PREFETCHWT1 = 3u * 64u + 0u, x86_cpu_AVX512_VBMI = 3u * 64u + 1u, x86_cpu_UMIP = 3u * 64u + 2u, x86_cpu_PKU = 3u * 64u + 3u, x86_cpu_OSPKE = 3u * 64u + 4u, x86_cpu_WAITPKG = 3u * 64u + 5u, x86_cpu_AVX512_VBMI2 = 3u * 64u + 6u, x86_cpu_SHSTK = 3u * 64u + 7u, x86_cpu_GFNI = 3u * 64u + 8u, x86_cpu_VAES = 3u * 64u + 9u, x86_cpu_VPCLMULQDQ = 3u * 64u + 10u, x86_cpu_AVX512_VNNI = 3u * 64u + 11u, x86_cpu_AVX512_BITALG = 3u * 64u + 12u, x86_cpu_INDEX_7_ECX_13 = 3u * 64u + 13u, x86_cpu_AVX512_VPOPCNTDQ = 3u * 64u + 14u, x86_cpu_INDEX_7_ECX_15 = 3u * 64u + 15u, x86_cpu_INDEX_7_ECX_16 = 3u * 64u + 16u, /* Note: Bits 17-21: The value of MAWAU used by the BNDLDX and BNDSTX instructions in 64-bit mode. */ x86_cpu_RDPID = 3u * 64u + 22u, x86_cpu_KL = 3u * 64u + 23u, x86_cpu_INDEX_7_ECX_24 = 3u * 64u + 24u, x86_cpu_CLDEMOTE = 3u * 64u + 25u, x86_cpu_INDEX_7_ECX_26 = 3u * 64u + 26u, x86_cpu_MOVDIRI = 3u * 64u + 27u, x86_cpu_MOVDIR64B = 3u * 64u + 28u, x86_cpu_ENQCMD = 3u * 64u + 29u, x86_cpu_SGX_LC = 3u * 64u + 30u, x86_cpu_PKS = 3u * 64u + 31u, /* CPUID.07H.0H:EDX. */ x86_cpu_INDEX_7_EDX_0 = 4u * 64u + 0u, x86_cpu_INDEX_7_EDX_1 = 4u * 64u + 1u, x86_cpu_AVX512_4VNNIW = 4u * 64u + 2u, x86_cpu_AVX512_4FMAPS = 4u * 64u + 3u, x86_cpu_FSRM = 4u * 64u + 4u, x86_cpu_UINTR = 4u * 64u + 5u, x86_cpu_INDEX_7_EDX_6 = 4u * 64u + 6u, x86_cpu_INDEX_7_EDX_7 = 4u * 64u + 7u, x86_cpu_AVX512_VP2INTERSECT = 4u * 64u + 8u, x86_cpu_INDEX_7_EDX_9 = 4u * 64u + 9u, x86_cpu_MD_CLEAR = 4u * 64u + 10u, x86_cpu_INDEX_7_EDX_11 = 4u * 64u + 11u, x86_cpu_INDEX_7_EDX_12 = 4u * 64u + 12u, x86_cpu_INDEX_7_EDX_13 = 4u * 64u + 13u, x86_cpu_SERIALIZE = 4u * 64u + 14u, x86_cpu_HYBRID = 4u * 64u + 15u, x86_cpu_TSXLDTRK = 4u * 64u + 16u, x86_cpu_INDEX_7_EDX_17 = 4u * 64u + 17u, x86_cpu_PCONFIG = 4u * 64u + 18u, x86_cpu_INDEX_7_EDX_19 = 4u * 64u + 19u, x86_cpu_IBT = 4u * 64u + 20u, x86_cpu_INDEX_7_EDX_21 = 4u * 64u + 21u, x86_cpu_AMX_BF16 = 4u * 64u + 22u, x86_cpu_AVX512_FP16 = 4u * 64u + 23u, x86_cpu_AMX_TILE = 4u * 64u + 24u, x86_cpu_AMX_INT8 = 4u * 64u + 25u, x86_cpu_IBRS_IBPB = 4u * 64u + 26u, x86_cpu_STIBP = 4u * 64u + 27u, x86_cpu_L1D_FLUSH = 4u * 64u + 28u, x86_cpu_ARCH_CAPABILITIES = 4u * 64u + 29u, x86_cpu_CORE_CAPABILITIES = 4u * 64u + 30u, x86_cpu_SSBD = 4u * 64u + 31u, /* CPUID.80000001H:ECX. */ x86_cpu_LAHF64_SAHF64 = 5u * 64u + 0u, x86_cpu_SVM = 5u * 64u + 2u, x86_cpu_LZCNT = 5u * 64u + 5u, x86_cpu_SSE4A = 5u * 64u + 6u, x86_cpu_PREFETCHW = 5u * 64u + 8u, x86_cpu_XOP = 5u * 64u + 11u, x86_cpu_LWP = 5u * 64u + 15u, x86_cpu_FMA4 = 5u * 64u + 16u, x86_cpu_TBM = 5u * 64u + 21u, /* CPUID.80000001H:EDX. */ x86_cpu_SYSCALL_SYSRET = 6u * 64u + 11u, x86_cpu_NX = 6u * 64u + 20u, x86_cpu_PAGE1GB = 6u * 64u + 26u, x86_cpu_RDTSCP = 6u * 64u + 27u, x86_cpu_LM = 6u * 64u + 29u, /* CPUID.(EAX=0DH,ECX=1):EAX. */ x86_cpu_XSAVEOPT = 7u * 64u + 0u, x86_cpu_XSAVEC = 7u * 64u + 1u, x86_cpu_XGETBV_ECX_1 = 7u * 64u + 2u, x86_cpu_XSAVES = 7u * 64u + 3u, x86_cpu_XFD = 7u * 64u + 4u, /* CPUID.80000007H:EDX. */ x86_cpu_INVARIANT_TSC = 8u * 64u + 8u, /* CPUID.80000008H:EBX. */ x86_cpu_WBNOINVD = 9u * 64u + 9u, /* CPUID.(EAX=07H.,ECX=1):EAX. */ x86_cpu_AVX_VNNI = 10u * 64u + 4u, x86_cpu_AVX512_BF16 = 10u * 64u + 5u, x86_cpu_FZLRM = 10u * 64u + 10u, x86_cpu_FSRS = 10u * 64u + 11u, x86_cpu_FSRCS = 10u * 64u + 12u, x86_cpu_HRESET = 10u * 64u + 22u, /* CPUID.19H:EAX. */ x86_cpu_AESKLE = 11u * 64u + 0u, x86_cpu_WIDE_KL = 11u * 64u + 2u, }; #endif /* _SYS_PLATFORM_X86_H */ ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-12-22 13:32 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-21 13:00 Compatibility issues around <sys/platform/x86.h> Florian Weimer 2020-12-21 17:05 ` H.J. Lu 2020-12-21 17:15 ` Adhemerval Zanella 2020-12-22 11:42 ` H.J. Lu 2020-12-22 12:43 ` Adhemerval Zanella 2020-12-22 12:57 ` H.J. Lu 2020-12-22 11:42 ` H.J. Lu 2020-12-22 13:32 ` Florian Weimer
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).