mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-27 06:34:11 +08:00
400e4b2091
'xsave.header::xstate_bv' is a misnomer - what does 'bv' stand for?
It probably comes from the 'XGETBV' instruction name, but I could
not find in the Intel documentation where that abbreviation comes
from. It could mean 'bit vector' - or something else?
But how about - instead of guessing about a weird name - we named
the field in an obvious and descriptive way that tells us exactly
what it does?
So rename it to 'xfeatures', which is a bitmask of the
xfeatures that are fpstate_active in that context structure.
Eyesore like:
fpu->state->xsave.xsave_hdr.xstate_bv |= XSTATE_FP;
is now much more readable:
fpu->state->xsave.header.xfeatures |= XSTATE_FP;
Which form is not just infinitely more readable, but is also
shorter as well.
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
64 lines
2.2 KiB
C
64 lines
2.2 KiB
C
#ifndef _ASM_X86_USER_H
|
|
#define _ASM_X86_USER_H
|
|
|
|
#ifdef CONFIG_X86_32
|
|
# include <asm/user_32.h>
|
|
#else
|
|
# include <asm/user_64.h>
|
|
#endif
|
|
|
|
#include <asm/types.h>
|
|
|
|
struct user_ymmh_regs {
|
|
/* 16 * 16 bytes for each YMMH-reg */
|
|
__u32 ymmh_space[64];
|
|
};
|
|
|
|
struct user_xstate_header {
|
|
__u64 xfeatures;
|
|
__u64 reserved1[2];
|
|
__u64 reserved2[5];
|
|
};
|
|
|
|
/*
|
|
* The structure layout of user_xstateregs, used for exporting the
|
|
* extended register state through ptrace and core-dump (NT_X86_XSTATE note)
|
|
* interfaces will be same as the memory layout of xsave used by the processor
|
|
* (except for the bytes 464..511, which can be used by the software) and hence
|
|
* the size of this structure varies depending on the features supported by the
|
|
* processor and OS. The size of the structure that users need to use can be
|
|
* obtained by doing:
|
|
* cpuid_count(0xd, 0, &eax, &ptrace_xstateregs_struct_size, &ecx, &edx);
|
|
* i.e., cpuid.(eax=0xd,ecx=0).ebx will be the size that user (debuggers, etc.)
|
|
* need to use.
|
|
*
|
|
* For now, only the first 8 bytes of the software usable bytes[464..471] will
|
|
* be used and will be set to OS enabled xstate mask (which is same as the
|
|
* 64bit mask returned by the xgetbv's xCR0). Users (analyzing core dump
|
|
* remotely, etc.) can use this mask as well as the mask saved in the
|
|
* xstate_hdr bytes and interpret what states the processor/OS supports
|
|
* and what states are in modified/initialized conditions for the
|
|
* particular process/thread.
|
|
*
|
|
* Also when the user modifies certain state FP/SSE/etc through the
|
|
* ptrace interface, they must ensure that the header.xfeatures
|
|
* bytes[512..519] of the memory layout are updated correspondingly.
|
|
* i.e., for example when FP state is modified to a non-init state,
|
|
* header.xfeatures's bit 0 must be set to '1', when SSE is modified to
|
|
* non-init state, header.xfeatures's bit 1 must to be set to '1', etc.
|
|
*/
|
|
#define USER_XSTATE_FX_SW_WORDS 6
|
|
#define USER_XSTATE_XCR0_WORD 0
|
|
|
|
struct user_xstateregs {
|
|
struct {
|
|
__u64 fpx_space[58];
|
|
__u64 xstate_fx_sw[USER_XSTATE_FX_SW_WORDS];
|
|
} i387;
|
|
struct user_xstate_header header;
|
|
struct user_ymmh_regs ymmh;
|
|
/* further processor state extensions go here */
|
|
};
|
|
|
|
#endif /* _ASM_X86_USER_H */
|