[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RISU v2 00/11] Support for i386/x86_64 with vector ext
Re: [Qemu-devel] [RISU v2 00/11] Support for i386/x86_64 with vector extensions
Thu, 23 May 2019 14:03:51 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
On 5/21/19 12:49 PM, Richard Henderson wrote:
> SSE2 is a mandatory part of the x86_64 ABI.
> I sincerely doubt we care about testing 32-bit that does not have SSE, but
> then this patch set will not fail, as the kernel will not include the SSE
> registers into the signal frame. It would be the actual test cases for SSE
> instructions that would SIGILL when run on a 32-bit guest w/o SSE.
Fair enough. I had no idea that SSE2 is mandatory in x86_64, that's
good to know. Let's keep the SSE default then.
> No, the assert is really an assert, because we have also masked the
> value against the set of features stored in the signal frame. If the kernel
> reports a feature in the signal frame for which there is no cpuid leaf, then
> something is very confused somewhere.
Ah, I see. Makes complete sense.
> I am not sure that we can validate that the features in the signal frame match
> the --xfeatures value, because I *think* that features are omitted from the
> XSAVE data structure when they are in init state. E.g. when we have not yet
> exercised the feature.
> This caveat is definitely true of ARM SVE, and I found that if I asserted that
> all of the SVE state was in the signal frame that the generated RISU test
> uses memory would fail the 1st checkpoint, because no SVE instructions had yet
> been executed.
> A careful reading of the XSAVE documentation, plus some experimentation, is
> definitely required. Maybe hand-craft a test case using XRSTOR, giving it a
> save area that specifies all features to be reset to init state.
tl;dr Richard is exactly right; a component may be missing from the
XSAVE region if it's in the "initial configuration." I'd just leave it
as it is now: it appears everything more advanced than the SSE state
is in the initial configuration when the test image starts
executing. It won't show up until there's instructions which actually
touch it, but by then we get a SIGILL if the HW doesn't support it.
Long story: The Intel manual definitely has a notion of "init
optimization," in addition to "modified optimization." Vol. 1, Section
13.6 "Processor Tracking of XSAVE Managed State" says:
The XSAVEOPT, XSAVEC, and XSAVES instructions use two optimizations
to reduce the amount of data that they write to memory. They avoid
writing data for any state component known to be in its initial
configuration (the init optimization). In addition, if either
XSAVEOPT or XSAVES is using the same XSAVE area as that used by the
most recent execution of XRSTOR or XRSTORS, it may avoid writing
data for any state component whose configuration is known not to
have been modified since then (the modified optimization). (XSAVE
does not use these optimizations, and XSAVEC does not use the
So, XSAVE does not use any optimizations, whereas all other XSAVE
variants use at least the init optimization. Furthermore,
The following notation describes the state of the init and modified
* XINUSE denotes the state-component bitmap corresponding to the
init optimization. If XINUSE[i] = 0, state component i is known to
be in its initial configuration; otherwise XINUSE[i] = 1. It is
possible for XINUSE[i] to be 1 even when state component i is in
its initial configuration. On a processor that does not support
the init optimization, XINUSE[i] is always 1 for every value of i.
The processor does not need to detect "return" to the initial
configuration; this makes more sense once it's clear what the initial
The following items specify the initial configuration each state
component (for the purposes of defining the XINUSE bitmap):
* SSE state. In 64-bit mode, SSE state is in its initial
configuration if each of XMM0–XMM15 is 0. Outside 64-bit mode, SSE
state is in its initial configuration if each of XMM0–XMM7 is
* AVX state. In 64-bit mode, AVX state is in its initial
configuration if each of YMM0_H–YMM15_H is 0. Outside 64-bit mode,
AVX state is in its initial configuration if each of YMM0_H–YMM7_H
is 0. [...]
No surprise here; the initial configuration is just all zeros.
I ran some experiments on my laptop's Intel(R) Core(TM) i5-4210U to
find out what actually happens. This CPU supports AVX (but not
AVX-512) and doesn't support XSAVEC, so I only looked at XSAVE and
XSAVEOPT (XSAVES is kernel-mode only). I found out that:
1. both XSAVE and XSAVEOPT do not include the AVX state if it is in
the initial configuration (not only XSAVEOPT),
2. return to initial configuration is not detected, i.e. the AVX state
is included even though it has been set to all zeros via vxorps,
3. the AVX state can be brought back to the initial configuration via
XRSTOR with the AVX component removed.
Description: OpenPGP digital signature
- [Qemu-devel] [RISU v2 08/11] configure: add i386/x86_64 architectures, (continued)
- [Qemu-devel] [RISU v2 08/11] configure: add i386/x86_64 architectures, Jan Bobek, 2019/05/17
- [Qemu-devel] [RISU v2 06/11] risu_i386: remove old unused code, Jan Bobek, 2019/05/17
- [Qemu-devel] [RISU v2 09/11] i386: Add avx512 state to reginfo_t, Jan Bobek, 2019/05/17
- Re: [Qemu-devel] [RISU v2 00/11] Support for i386/x86_64 with vector extensions, Alex Bennée, 2019/05/18
- Re: [Qemu-devel] [RISU v2 00/11] Support for i386/x86_64 with vector extensions, Alex Bennée, 2019/05/20