On 12/06/2013 05:46 AM, Borislav Petkov wrote: > > I'm guessing this and the struct lwp_struct above is being added so that > you can have the LWP XSAVE area size? If so, you don't need it: LWP > XSAVE area is 128 bytes at offset 832 according to my manuals so I'd > guess having a u8 lwp_area[128] should be fine. > Sure, but any reason to *not* document the internal structure? > >> + struct bndregs_struct bndregs; >> + struct bndcsr_struct bndcsr; >> /* new processor state extensions will go here */ >> } __attribute__ ((packed, aligned (64))); >> >> diff --git a/arch/x86/include/asm/xsave.h b/arch/x86/include/asm/xsave.h >> index 0415cda..5cd9de3 100644 >> --- a/arch/x86/include/asm/xsave.h >> +++ b/arch/x86/include/asm/xsave.h >> @@ -9,6 +9,8 @@ >> #define XSTATE_FP 0x1 >> #define XSTATE_SSE 0x2 >> #define XSTATE_YMM 0x4 >> +#define XSTATE_BNDREGS 0x8 >> +#define XSTATE_BNDCSR 0x10 >> >> #define XSTATE_FPSSE (XSTATE_FP | XSTATE_SSE) >> >> @@ -20,10 +22,12 @@ >> #define XSAVE_YMM_SIZE 256 >> #define XSAVE_YMM_OFFSET (XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET) >> >> +#define XSTATE_FLEXIBLE (XSTATE_FP | XSTATE_SSE | XSTATE_YMM) > > What's the use of that macro if it is used only once? Documentation seems good enough. Explicitly separating out the features which MUST be eagerly saved seems like a good thing. >> +#define XSTATE_EAGER (XSTATE_BNDREGS | XSTATE_BNDCSR) >> /* >> * These are the features that the OS can handle currently. >> */ >> -#define XCNTXT_MASK (XSTATE_FP | XSTATE_SSE | XSTATE_YMM) >> +#define XCNTXT_MASK (XSTATE_FLEXIBLE | XSTATE_EAGER) >> -hpa -- 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
