1 files changed, 30 insertions, 0 deletions
diff --git a/website/content/en/status/report-2021-10-2021-12/avx-bug.adoc b/website/content/en/status/report-2021-10-2021-12/avx-bug.adoc
new file mode 100644
index 0000000000..4b99fab1ab
--- /dev/null
+++ b/website/content/en/status/report-2021-10-2021-12/avx-bug.adoc
@@ -0,0 +1,30 @@
+=== The AVX bug on amd64
+
+Commit: gitref:73b357be92385cbb70ba19e7023a736af2c6b493[repository=src] URL: link:https://cgit.freebsd.org/src/commit/?id=73b357be92385cbb70ba19e7023a736af2c6b493[https://cgit.freebsd.org/src/commit/?id=73b357be92385cbb70ba19e7023a736af2c6b493]
+
+Contact: Konstantin Belousov <kib@FreeBSD.org>
+
+Some CPUs support the so called init optimization for XSAVE, but not all CPUs
+do.  And when they do, 'according to complex internal microarchitectural
+conditions', the optimization might happen or not.  Basically, this
+means that sometimes the CPU does not write all of the state on
+XSAVE and records in xstate_bv that it did not.
+
+On signal delivery, the OS provides the saved context interrupted by
+the signal to the signal handler.  The context includes all CPU state
+available to userspace, including FPU registers (XSAVE area).  Also,
+on return from the signal handler, context is restored, which
+allows the handler to modify the main program flow.
+When init optimization kicks in, the OS tries to hide init state
+optimization from the signal handler, by filling non-saved parts of
+the XSAVE area.
+
+This is where the problem happens.  For states parts 0 (x87) and 1
+(SSE/XMM), Intel CPUs do not provide an enumeration of layout in CPUID,
+assuming that the OS knows about the regions anyway. The bug was that
+the amd64 kernel hardcoded a 32bit size for the XMM save area, effectively
+filling %XMM8-%XMM15 with garbage on signal return when init
+optimization kicked in, because only specified part of the SSE save
+area was copied from the canonical save area.
+
+Sponsor: The FreeBSD Foundation