[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 05/10] Clear AC bit in RFLAGS to protect Xen itself by SMAP
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > Sent: Thursday, May 08, 2014 2:54 PM > To: Wu, Feng > Cc: Andrew Cooper; ian.campbell@xxxxxxxxxx; Dong, Eddie; Nakajima, Jun; Tian, > Kevin; xen-devel@xxxxxxxxxxxxx > Subject: RE: [PATCH v6 05/10] Clear AC bit in RFLAGS to protect Xen itself by > SMAP > > >>> On 08.05.14 at 08:49, <feng.wu@xxxxxxxxx> wrote: > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] > >> >>> On 08.05.14 at 04:02, <feng.wu@xxxxxxxxx> wrote: > >> > Sure, thanks for the suggestion! I will pass 0 to SAVE_ALL. > >> > My point is that ASM_STAC should be deferred as much as possible. > >> > >> There's no point in deferring it as much as possible if you don't CLAC > >> earlier on. In fact I'm inclined to ask to make the SAVE_ALL parameter > >> a tristate, allowing both CLAC and STAC to be done right there. > > > > Currently, there is only one place where we need to set AC around SAVE_ALL, > > it is double_fault. > > Do we really need to make SAVE_ALL that way? > > Note that I wrote "I'm inclined to ask ...", not "I'd like to ask ...", i.e. > if you feel uncomfortable with this, I'm still fine with leaving the macro > as is. But my argument stands that deferring STAC here as much as > possible is pointless. > > Jan Yes, I agree that it is pointless to defer STAC here. I am definitely fine with making SAVE_ALL Parameter a tristate. If you think it is better I am willing the change the patch. However, my question is that is it better to implement SAVE_ALL that way? Just a technical question!:) Thanks, Feng _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |