linux-kernel - [RFC v3 0/8] x86, xsave: rework of extended state handling, LWP support

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1302018656-586370-1-git-send-email-hans.rosenfeld@amd.com>
Date:	Tue, 5 Apr 2011 17:50:48 +0200
From:	Hans Rosenfeld <hans.rosenfeld@....com>
To:	<hpa@...or.com>
CC:	<brgerst@...il.com>, <tglx@...utronix.de>, <mingo@...e.hu>,
	<suresh.b.siddha@...el.com>, <eranian@...gle.com>,
	<robert.richter@....com>, <Andreas.Herrmann3@....com>,
	<x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	Hans Rosenfeld <hans.rosenfeld@....com>
Subject: [RFC v3 0/8] x86, xsave: rework of extended state handling, LWP support

Changes since last patch set:
* fixed pre-allocation of xsave area to exclude kernel threads


This patch set is a general cleanup and rework of the code related to
handling of FPU and other extended states.

All handling of extended states, including the FPU state, is now handled
by xsave/xrstor wrappers that fall back to fxsave/fxrstor, or even
fsave/frstor, if hardware support for those features is lacking.  

Non-lazy xstates, which cannot be restored lazily, can now be easily 
supported with almost no processing overhead. This makes adding basic
support for AMDs LWP almost trivial.

Since non-lazy xstates are inherently incompatible with lazy allocation 
of the xstate area, the complete removal of lazy allocation to further  
reduce code complexity should be considered. Since SSE-optimized library
functions are widely used today, most processes will have an xstate area
anyway, so the memory overhead wouldn't be big enough to be much of an
issue.

Hans Rosenfeld (8):
  x86, xsave: cleanup fpu/xsave support
  x86, xsave: rework fpu/xsave support
  x86, xsave: cleanup fpu/xsave signal frame setup
  x86, xsave: remove unused code
  x86, xsave: more cleanups
  x86, xsave: add support for non-lazy xstates
  x86, xsave: add kernel support for AMDs Lightweight Profiling (LWP)
  x86, xsave: remove lazy allocation of xstate area

 arch/x86/ia32/ia32_signal.c        |    4 +-
 arch/x86/include/asm/i387.h        |  249 ++++++++--------------------
 arch/x86/include/asm/msr-index.h   |    1 +
 arch/x86/include/asm/processor.h   |   12 ++
 arch/x86/include/asm/sigcontext.h  |   12 ++
 arch/x86/include/asm/thread_info.h |    4 +-
 arch/x86/include/asm/xsave.h       |  100 ++---------
 arch/x86/kernel/i387.c             |  305 +++-------------------------------
 arch/x86/kernel/process_32.c       |   29 +--
 arch/x86/kernel/process_64.c       |   28 +---
 arch/x86/kernel/signal.c           |    4 +-
 arch/x86/kernel/traps.c            |   47 +-----
 arch/x86/kernel/xsave.c            |  317 +++++++++++++++++++++++-------------
 arch/x86/kvm/vmx.c                 |    2 +-
 arch/x86/kvm/x86.c                 |   11 +-
 arch/x86/math-emu/fpu_entry.c      |    8 +-
 drivers/lguest/x86/core.c          |    2 +-
 17 files changed, 388 insertions(+), 747 deletions(-)


--
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/