From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Wu, Feng" <feng.wu@intel.com>
Cc: "Nakajima, Jun" <jun.nakajima@intel.com>,
"Dong, Eddie" <eddie.dong@intel.com>,
"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions
Date: Tue, 22 Apr 2014 09:09:54 -0400 [thread overview]
Message-ID: <20140422130954.GC3672@phenom.dumpdata.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F001F2E9A5@SHSMSX104.ccr.corp.intel.com>
On Tue, Apr 22, 2014 at 12:19:48PM +0000, Wu, Feng wrote:
>
>
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Tuesday, April 22, 2014 5:17 PM
> > To: Wu, Feng
> > Cc: Ian.Campbell@citrix.com; Dong, Eddie; Nakajima, Jun;
> > xen-devel@lists.xen.org
> > Subject: RE: [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions
> >
> > >>> On 22.04.14 at 10:46, <feng.wu@intel.com> wrote:
> > >> From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> >>> On 22.04.14 at 09:41, <feng.wu@intel.com> 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.
>
> > Jan
>
> Thanks,
> Feng
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-04-22 13:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 13:01 [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions Feng Wu
2014-04-15 8:40 ` Jan Beulich
2014-04-22 7:41 ` Wu, Feng
2014-04-22 8:07 ` Jan Beulich
2014-04-22 8:46 ` Wu, Feng
2014-04-22 9:17 ` Jan Beulich
2014-04-22 12:19 ` Wu, Feng
2014-04-22 13:09 ` Konrad Rzeszutek Wilk [this message]
2014-04-23 13:43 ` Wu, Feng
2014-04-23 14:52 ` Is: alternative_asm as dependency for STAC/CLAC/new features? Was:Re: " Konrad Rzeszutek Wilk
2014-04-23 15:59 ` Is: alternative_asm as dependency for STAC/CLAC/new features? Jan Beulich
2014-04-22 9:43 ` [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions Andrew Cooper
2014-04-22 9:48 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140422130954.GC3672@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=eddie.dong@intel.com \
--cc=feng.wu@intel.com \
--cc=jun.nakajima@intel.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.