It is mentioned that ERESUME will fail if the XSAVE area is not consistent with XFRM.
However, how can this happen when EENTER will change the XCR0 to XFRM?
A successful execution of ENCLU[ERESUME] loads state from the XSAVE area of the SSA frame in a fashion similar to that used by the XRSTOR instruction. Data in the XSAVE area that would cause the XRSTOR instruction to fault will cause the ENCLU[ERESUME] instruction to fault.
Examples include the following:
Any of these conditions will cause ERESUME to fault, even if CR4.OSXSAVE=0. In this case, it is the responsibility of the processor to generate faults that are caused by XRSTOR and not by FXRSTOR.
If ENCLU[ERESUME] is successful, it saves the current value of XCR0 microarchitecturally and sets XCR0 to XFRM. State is loaded from the XSAVE area of the SSA frame as if the XRSTOR instruction were executed with XCR0=XFRM, EDX:EAX = XFRM, with the memory operand being the XSAVE area, and (for 64-bit enclaves) as if REX.W=1. The XSTATE_BV part of the XSAVE header is saved with 0 for every bit that is 0 in XFRM, as a noncompacted buffer. Other bits may be saved as 0 if the state saved is initialized.
ENCLU[ERESUME] ensures that a subsequent execution of XSAVEOPT inside the enclave will operate properly (e.g.,
by marking all state as modified).