lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 16 Sep 2014 15:22:27 +0200 From: Ingo Molnar <mingo@...nel.org> To: Nadav Amit <namit@...technion.ac.il> Cc: pbonzini@...hat.com, hpa@...or.com, mingo@...hat.com, tglx@...utronix.de, x86@...nel.org, kvm@...r.kernel.org, nadav.amit@...il.com, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Borislav Petkov <bp@...en8.de> Subject: Re: [PATCH 0/3] x86: structs for cpuid info in x86 * Nadav Amit <namit@...technion.ac.il> wrote: > The code that deals with x86 cpuid fields is hard to follow since it performs > many bit operations and does not refer to cpuid field explicitly. To > eliminate the need of openning a spec whenever dealing with cpuid fields, this > patch-set introduces structs that reflect the various cpuid functions. > > Thanks for reviewing the patch-set. > > Nadav Amit (3): > x86: Adding structs to reflect cpuid fields > x86: Use new cpuid structs in cpuid functions > KVM: x86: Using cpuid structs in KVM > > arch/x86/include/asm/cpuid_def.h | 163 +++++++++++++++++++++++++++++++++++++++ > arch/x86/kernel/cpu/common.c | 56 ++++++++------ > arch/x86/kvm/cpuid.c | 36 +++++---- > 3 files changed, 219 insertions(+), 36 deletions(-) > create mode 100644 arch/x86/include/asm/cpuid_def.h I personally like bitfields in theory (they provide type clarity and abstract robustness, compared to open-coded bitmask numeric literals that are often used in cpuid using code, obfuscating cpuid usage), with the big caveat that for many years I didn't like bitfields in practice: older versions of GCC did a really poor job of optimizing them. So such a series would only be acceptable if it's demonstrated that both 'latest' and 'reasonably old' GCC versions do a good job in that department, compared to the old open-coded bitmask ops ... Comparing the 'size vmlinux' output of before/after kernels would probably be a good start in seeing the impact of such a change. If those results are positive then this technique could be propagated to all cpuid using code in arch/x86/, of which there's plenty. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists