2016-04-23 1:21 GMT+08:00 David Matlack <dmatlack@xxxxxxxxxx>: > On Fri, Apr 22, 2016 at 12:30 AM, Wanpeng Li <kernellwp@xxxxxxxxx> wrote: >> Hi Paolo and David, >> 2016-03-31 3:24 GMT+08:00 David Matlack <dmatlack@xxxxxxxxxx>: >>> >>> kernel_fpu_begin() saves the current fpu context. If this uses >>> XSAVE[OPT], it may leave the xsave area in an undesirable state. >>> According to the SDM, during XSAVE bit i of XSTATE_BV is not modified >>> if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and >>> xcr0[i] == 0 following an XSAVE. >> >> How XSAVE save bit i since SDM mentioned that "XSAVE saves state >> component i if and only if RFBM[i] = 1. "? RFBM[i] will be 0 if >> XSTATE_BV[i] == 1 && guest xcr0[i] == 0. > > You are correct, RFBM[i] will be 0 and XSAVE does not save state > component i in this case. However, XSTATE_BV[i] is left untouched by > XSAVE (left as 1). On XRSTOR, the CPU checks if XSTATE_BV[i] == 1 && > xcr0[i] == 0, and if so delivers a #GP. However, SDM also mentioned that "If RFBM[i] = 0, XRSTOR does not update state component i." So we #GP on a don't need restore bit i if XSTATE_BV[I] == 1 && xcr0[0] ==0. That's where I miss I think, thanks for your explanation. Regard, Wanpeng Li > > If you are wondering how XSTATE_BV[i] could be 1 in the first place, I > suspect it is left over from a previous XSAVE (which sets XSTATE_BV[i] > to the value in XINUSE[i]). -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html