lkml.org 
[lkml]   [2014]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] x86: structs for cpuid info in x86

* Nadav Amit <namit@cs.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


\
 
 \ /
  Last update: 2014-09-16 16:01    [W:2.249 / U:2.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site