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

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

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Tuesday, April 22, 2014 9:10 PM
> To: Wu, Feng
> Cc: Jan Beulich; Dong, Eddie; Ian.Campbell@xxxxxxxxxx; Nakajima, Jun;
> xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v1 1/6] x86: Add support for STAC/CLAC
> instructions
> 
> On Tue, Apr 22, 2014 at 12:19:48PM +0000, Wu, Feng wrote:
> >
> >
> > > -----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.
> 
> Any time estimates when the alternative patching mechanism would be done?
> Asking
> because it seems to me that we would want that in Xen 4.5 - so need to figure
> out
> your timeline to fold it in the release time-frame.

I am sorry I feel it is a little hard for me to say when the patch will be 
done, since I am not
quite clear about how big the effort would be right now. But I can start 
porting it ASAP
after SMAP is done. BTW, do you know when will Xen 4.5 be released? About 4~5 
months later?

> 
> >
> > > Jan
> >
> > Thanks,
> > Feng
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel

Thanks,
Feng

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