amd64: handle MXCSR from XSAVEOPT when x87 state was optimized

[kib]

Summary

PR: 275322
Reported by: Cheyenne Wills <[e-mail]>

[emaste]

I'm not fully familiar with the xsave details - I'm curious why this was AMD-specific (and/or, what implies that the x87 area was not saved, in the new block)?

[kib]

AMD-specific thing there is that X87 state was not saved, as reported by xstate_bv.bit0 == 0 (I believe Intel always saves X87). But regardless of that, MXCSR state is always saved even if X87 is not. By overwriting X87 non-saved area with the default content, we also override the potentially changed MXCSR, which was reported in the PR.

[jhb]

Presumably i386 needs the same fixup as well?

What an odd bug.

sys/amd64/amd64/fpu.c

888

AVX512? Realistically I suspect anything using AVX512 will also be dirtying AVX state (and really AVX should always imply SSE so you could maybe even get by with only checking SSE here?)

892

[kib]

sys/amd64/amd64/fpu.c

888

Literally, Intel SDM states

IF RFBM[1] = 1 or RFBM[2] = 1
   THEN store MXCSR and MXCSR_MASK into legacy region of XSAVE area;
FI;

But now I think that the mask must be saved as well.

[kib]

Handle i386

[emaste]

sys/amd64/amd64/fpu.c

905–908

we write this each time through the loop?

[kib]

sys/amd64/amd64/fpu.c

905–908

Indeed. This is not incorrect but excessive of course.

[kib]

Initialize do_mxcsr on each iteration.

[olce]

sys/amd64/amd64/fpu.c

888

The Intel SDM also states that, when XSAVEC is used, only RFBM[1] set causes MXCSR and MXCSR_MASK to be stored. So shouldn't the newly introduced if be changed to deal with this situation, by testing only for RFBM[1], or RFBM[1] and RFBM[2], depending on whether XCOMP_BV[63] is set (flag for the compact format)?

[kib]

sys/amd64/amd64/fpu.c

888

We do not use XSAVEC. This code needs to be completely revamped to accomodate XSAVEC.