lkml.org 
[lkml]   [2013]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition
Date

> -----Original Message-----
> From: Liu, Jinsong
> Sent: Saturday, December 07, 2013 6:13 AM
> To: H. Peter Anvin; Paolo Bonzini; Ren, Qiaowei
> Cc: kvm@vger.kernel.org; x86@kernel.org; Xudong Hao;
> qemu-devel@nongnu.org; linux-kernel@vger.kernel.org; Ingo Molnar; Thomas
> Gleixner
> Subject: RE: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature
> definition
>
> H. Peter Anvin wrote:
> > On 12/06/2013 12:05 PM, Liu, Jinsong wrote:
> >>>
> >>> Since Peter already said the same, please undo these changes.
> >>>
> >>> Also, how is XSTATE_EAGER used? Should MPX be disabled when
> >>> xsaveopt is disabled on the kernel command line? (Liu, how would
> >>> this affect the KVM patches, too?)
> >>>
> >>> Paolo
> >>
> >> Currently seems no, and if needed we can add a new patch at kvm side
> >> accordingly when native mpx patches checked in.
> >>
> >
> > We need to either disable these features in lazy mode, or we need to
> > force eager mode if these features are to be supported. The problem
> > with the latter is that it means forcing eager mode regardless of if
> > anything actually *uses* these features.
> >
> > A third option would be to require applications to use a prctl() or
> > similar to enable eager-save features.
> >
> > Thoughts?
> >
> > -hpa
>
> The third option seems better -- how does native mpx patches work, force
> eager?
>
It should be the second option, as you can see xsave.c which we remove from this patch. :)

Thanks,
Qiaowei


\
 
 \ /
  Last update: 2013-12-07 01:41    [W:2.780 / U:3.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site