* Nadav Amit <namit@xxxxxxxxxxxxxxxxx> 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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
