All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <bp@alien8.de>, Qiaowei Ren <qiaowei.ren@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Xudong Hao <xudong.hao@intel.com>,
	Liu Jinsong <jinsong.liu@intel.com>
Subject: Re: [PATCH 3/3] X86, mpx: Intel MPX xstate feature definition
Date: Fri, 06 Dec 2013 09:23:22 -0800	[thread overview]
Message-ID: <52A2080A.9010208@zytor.com> (raw)
In-Reply-To: <20131206134631.GD6694@pd.tnic>

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

WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Borislav Petkov <bp@alien8.de>, Qiaowei Ren <qiaowei.ren@intel.com>
Cc: Liu Jinsong <jinsong.liu@intel.com>,
	kvm@vger.kernel.org, x86@kernel.org,
	Xudong Hao <xudong.hao@intel.com>,
	qemu-devel@nongnu.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Qemu-devel] [PATCH 3/3] X86, mpx: Intel MPX xstate feature definition
Date: Fri, 06 Dec 2013 09:23:22 -0800	[thread overview]
Message-ID: <52A2080A.9010208@zytor.com> (raw)
In-Reply-To: <20131206134631.GD6694@pd.tnic>

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

  parent reply	other threads:[~2013-12-06 17:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06 18:52 [PATCH 1/3] x86, mpx: add documentation on Intel MPX Qiaowei Ren
2013-12-06 18:52 ` [Qemu-devel] " Qiaowei Ren
2013-12-06 13:26 ` Borislav Petkov
2013-12-06 13:26   ` [Qemu-devel] " Borislav Petkov
2013-12-06 15:55   ` Ren, Qiaowei
2013-12-06 15:55     ` [Qemu-devel] " Ren, Qiaowei
2013-12-06 15:55     ` Ren, Qiaowei
2013-12-06 16:06     ` Borislav Petkov
2013-12-06 16:06       ` [Qemu-devel] " Borislav Petkov
2013-12-06 16:11       ` Ren, Qiaowei
2013-12-06 16:11         ` [Qemu-devel] " Ren, Qiaowei
2013-12-06 16:11         ` Ren, Qiaowei
2013-12-06 18:52 ` [PATCH 2/3] X86, mpx: Intel MPX definition Qiaowei Ren
2013-12-06 18:52   ` [Qemu-devel] " Qiaowei Ren
2013-12-06 13:33   ` Borislav Petkov
2013-12-06 13:33     ` [Qemu-devel] " Borislav Petkov
2013-12-06 15:58     ` H. Peter Anvin
2013-12-06 15:58       ` [Qemu-devel] " H. Peter Anvin
2013-12-06 18:52 ` [PATCH 3/3] X86, mpx: Intel MPX xstate feature definition Qiaowei Ren
2013-12-06 18:52   ` [Qemu-devel] " Qiaowei Ren
2013-12-06 13:46   ` Borislav Petkov
2013-12-06 13:46     ` [Qemu-devel] " Borislav Petkov
2013-12-06 16:08     ` Ren, Qiaowei
2013-12-06 16:08       ` [Qemu-devel] " Ren, Qiaowei
2013-12-06 16:08       ` Ren, Qiaowei
2013-12-06 17:23     ` H. Peter Anvin [this message]
2013-12-06 17:23       ` [Qemu-devel] " H. Peter Anvin
2013-12-06 18:55       ` Borislav Petkov
2013-12-06 18:55         ` [Qemu-devel] " Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52A2080A.9010208@zytor.com \
    --to=hpa@zytor.com \
    --cc=bp@alien8.de \
    --cc=jinsong.liu@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qiaowei.ren@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xudong.hao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.