On 2014-06-20, H. Peter Anvin wrote:
> On 06/19/2014 10:04 AM, Dave Hansen wrote:
>>
>> Could you please support this position with some data? I'm a bit
>> skeptical that instruction decoding is going to be a
>> performance-critical path.
>>
>> I also don't see the extra field that you talked
On 06/19/2014 10:04 AM, Dave Hansen wrote:
>
> Could you please support this position with some data? I'm a bit
> skeptical that instruction decoding is going to be a
> performance-critical path.
>
> I also don't see the extra field that you talked about in the previous
> thread? What's the
On 06/18/2014 11:53 PM, Ren, Qiaowei wrote:
> On 2014-06-19, Borislav Petkov wrote:
>> On Thu, Jun 19, 2014 at 01:13:48AM +, Ren, Qiaowei wrote:
>>> On 2014-06-18, Borislav Petkov wrote:
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
This whole insn decoding
On 2014-06-19, Borislav Petkov wrote:
> On Thu, Jun 19, 2014 at 01:13:48AM +, Ren, Qiaowei wrote:
>> On 2014-06-18, Borislav Petkov wrote:
>>> On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
>>>
>>> This whole insn decoding machinery above looks like adapted from
>>>
On Thu, Jun 19, 2014 at 01:13:48AM +, Ren, Qiaowei wrote:
> On 2014-06-18, Borislav Petkov wrote:
> > On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
> >
> > This whole insn decoding machinery above looks like adapted from
> > arch/x86/lib/insn.c. You should merge it with the
On Thu, Jun 19, 2014 at 01:13:48AM +, Ren, Qiaowei wrote:
On 2014-06-18, Borislav Petkov wrote:
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
This whole insn decoding machinery above looks like adapted from
arch/x86/lib/insn.c. You should merge it with the generic code
On 2014-06-19, Borislav Petkov wrote:
On Thu, Jun 19, 2014 at 01:13:48AM +, Ren, Qiaowei wrote:
On 2014-06-18, Borislav Petkov wrote:
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
This whole insn decoding machinery above looks like adapted from
arch/x86/lib/insn.c. You
On 06/18/2014 11:53 PM, Ren, Qiaowei wrote:
On 2014-06-19, Borislav Petkov wrote:
On Thu, Jun 19, 2014 at 01:13:48AM +, Ren, Qiaowei wrote:
On 2014-06-18, Borislav Petkov wrote:
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
This whole insn decoding machinery above looks
On 06/19/2014 10:04 AM, Dave Hansen wrote:
Could you please support this position with some data? I'm a bit
skeptical that instruction decoding is going to be a
performance-critical path.
I also don't see the extra field that you talked about in the previous
thread? What's the extra
On 2014-06-20, H. Peter Anvin wrote:
On 06/19/2014 10:04 AM, Dave Hansen wrote:
Could you please support this position with some data? I'm a bit
skeptical that instruction decoding is going to be a
performance-critical path.
I also don't see the extra field that you talked about in the
On 2014-06-18, Borislav Petkov wrote:
> On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
>
> This whole insn decoding machinery above looks like adapted from
> arch/x86/lib/insn.c. You should merge it with the generic code in
> insn.c instead of homegrowing it here only for the
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
> This patch sets bound violation fields of siginfo struct in #BR
> exception handler by decoding the user instruction and constructing
> the faulting pointer.
>
> Signed-off-by: Qiaowei Ren
> ---
> arch/x86/include/asm/mpx.h | 23
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
This patch sets bound violation fields of siginfo struct in #BR
exception handler by decoding the user instruction and constructing
the faulting pointer.
Signed-off-by: Qiaowei Ren qiaowei@intel.com
---
On 2014-06-18, Borislav Petkov wrote:
On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
This whole insn decoding machinery above looks like adapted from
arch/x86/lib/insn.c. You should merge it with the generic code in
insn.c instead of homegrowing it here only for the purposes of
14 matches
Mail list logo
