http://bugs.winehq.org/show_bug.cgi?id=58420
--- Comment #4 from pipcet@protonmail.com --- (In reply to Bernhard Übelacker from comment #3)
If I understand this right this issue makes wine getting an exception in a xsave instruction?
Yes, but the xsave instruction itself behaves correctly. It sees an unaligned pointer and throws a general protection fault, as it is documented to do.
There might be a chance to workaround by adding something to the function emulate_instruction for this case?
That would mean making xsave work with an unaligned buffer, IIUC.
It'd be very tricky: we would need to copy the correct xsave state from the context (we can't just execute xsave to a temp buffer because our xstate might be different from the state of the interrupted process), and it's possible that the layout would be different so we'd need to parse and rebuild it. That's a lot of effort for a workaround.
It seems quite unlikely any program relies on the fact that xsave to an unaligned area does not work. Still, it's possible that the workaround would break more than it fixes.
However, these are new CPUs, so arch_prctl(ARCH_GET_CPUID) might be available, which would let us trap (just) the CPUID instruction and align the reported maximum size of the XSAVE area. I don't know whether that's an option, particularly since the relevant flag is cleared by execve().
There's no really good option here: if we have to live with the latest and greatest features being enabled by Linux, in XCR0 and the other control registers, then those features will become visible to Wine-run programs years before Windows implements them, and some of those programs will break.
I imagine that'll be a nightmare for APX (which interacts with xsave in very strange ways, using a different order for the storage areas depending on whether xsavec or xsave is used).