On 12/06/2013 09:35 AM, Paolo Bonzini wrote:
> > Sorry for the back-and-forth, but I think this and the removal of> XSTATE_FLEXIBLE (perhaps XSTATE_LAZY?) makes your v2 worse than v1.> > 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?)>
There are two options: we could disable MPX etc. or we could force eager
saving (using xsave) even if xsaveopt is disabled. It is a hard call to
make, but I guess I'm leaning towards the latter; we could add an
"lazyxsave" option to explicitly disable all eager features if there is
use for that.
-hpa

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

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?
Thanks,
Jinsong

On 12/06/2013 04:23 PM, Ren, Qiaowei wrote:
>>>>>> 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.>>>>>>> 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. :)>
Ah yes... I missed the fact that that chunk had been dropped from this
patch. It really shouldn't be.
I'll substitute the previous version of the patch.
-hpa

On 12/06/2013 05:16 PM, Ren, Qiaowei wrote:
> Jinsong think that both kvm and host depend on these feature definition header file, so we firstly submit these files depended on.
Yes, but we can't turn on the feature without proper protection. Either
way, they are now in tip:x86/cpufeature.
-hpa