[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.