qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature defin


From: Ren, Qiaowei
Subject: Re: [Qemu-devel] [PATCH v2 3/3] X86, mpx: Intel MPX xstate feature definition
Date: Sat, 7 Dec 2013 00:23:23 +0000

> -----Original Message-----
> From: Liu, Jinsong
> Sent: Saturday, December 07, 2013 6:13 AM
> To: H. Peter Anvin; Paolo Bonzini; Ren, Qiaowei
> Cc: address@hidden; address@hidden; Xudong Hao;
> address@hidden; address@hidden; 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]