From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v1 1/6] x86: Add support for STAC/CLAC instructions Date: Tue, 22 Apr 2014 09:09:54 -0400 Message-ID: <20140422130954.GC3672@phenom.dumpdata.com> References: <1397566876-19631-1-git-send-email-feng.wu@intel.com> <534D0C830200007800008D72@nat28.tlf.novell.com> <53563F4D020000780000A927@nat28.tlf.novell.com> <53564FBD020000780000AA4A@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" Cc: "Nakajima, Jun" , "Dong, Eddie" , "Ian.Campbell@citrix.com" , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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, wrote: > > >> From: Jan Beulich [mailto:JBeulich@suse.com] > > >> >>> On 22.04.14 at 09:41, 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