Re: [Xen-devel] [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, April 22, 2014 5:17 PM
> To: Wu, Feng
> Cc: Ian.Campbell@xxxxxxxxxx; Dong, Eddie; Nakajima, Jun;
> xen-devel@xxxxxxxxxxxxx
> Subject: RE: [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions
> 
> >>> On 22.04.14 at 10:46, <feng.wu@xxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >>> On 22.04.14 at 09:41, <feng.wu@xxxxxxxxx> wrote:
> >> > BTW, from the Linux implementation, I think we don't need to check the
> 'cr4'
> >> > for the macros, we just need
> >> > to check whether the feature exists in the CPU. So is it acceptable to 
> >> > use
> >> > the original code by eliminating the cr4 check?
> >>
> >> That _might_ be acceptable if you bring it down to just the three
> >> really necessary instructions: BT, JNC, CLAC/STAC. But the "might"
> >> has to stand - this, after all, remains an addition of a conditional
> >> branch (and for the performance of STAC/CLAC I haven't seen any
> >> documentation so far either) to several fast paths, and hence the
> >> patching alternative can't be discarded as the potentially better one.
> >>
> >
> > Since the alternatives mechanism in Linux is something common and
> > independent and needs
> > a bit more efforts to be ported to Xen, can we use the method I mentioned
> > above
> > at the current stage. After that I will have a fully think about how to port
> > the
> > alternatives mechanism Xen.
> >
> > What do you think about this?
> 
> Generally this would seem acceptable (as long as you give at least a
> rough estimate on when to expect that second step), but then we
> have this sad experience with promises by Intel engineers to work
> on certain things...
> 

Thanks a lot!
I think I can work on the alternative mechanism after this SMAP patch is 
finished.

> Jan

Thanks,
Feng

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel