0

When is it allowed to call xsaves and xsaves64?

Using Intel Software Development Emulator (8.12.0-2017-10-23), I can use xsaves64 + xrstors64 from user-space without any problems, but trying to use xsaves + xrstors produces:

Illegal instruction at address = 11179a2015: 41 0f c7 28 48 8d bc 24 80 00 00 00 e8 ba e6

The same applies to xsavec, which produces:

SDE ERROR: header_cm == header_bv Trackers are NYI, therefore CM should be the same as BV

Are the non _64 variants of xsave_ and xrstor_ disallowed in 64-bit mode ?

gnzlbg
  • 7,135
  • 5
  • 53
  • 106
  • What CPU are you using? AFAIK `xsaves` is only available for 6th gen Intel Core CPUs. – Macmade Nov 21 '17 at 18:25
  • I am using Intel's SDE and an i7-7700k to test this. CPUID says that: `xsave` and `xsaves` are available, `oxsave` is set, `avx` is available, and `XCR0.SSE[1]` and `XCR0.AVX[2]` are set. Also `xsaves64` does work. So I am trying to figure out why `xsaves` produces an Access violation on the real hardware, and those errors in the SDE. – gnzlbg Nov 21 '17 at 18:37
  • The `SDE ERROR` message suggests a bug or limitation in the emulator. – Ross Ridge Nov 21 '17 at 18:45
  • 1
    I would guess that NYI stands for "not yet implemented". But I don't know what "trackers" means, so that's not much help. – prl Nov 22 '17 at 05:59
  • 1
    [According to the manual](https://hjlebbink.github.io/x86doc/html/XSAVES.html), *`XSAVES` may be executed only if CPL = 0*. The trailing S stands for "Supervisor". But I guess you're using SDE to simulate ring 0 in user-space? The manual says `xsaves` is valid in long mode and compat mode. It's not clear from the vol.2 manual what the difference is (i.e. how REX.W changes the behaviour of the instruction). Also note that `CR4.OSXSAVE[bit 18]` has to be set to 1 to enable the instruction, but that applies to both 64 and non-64. – Peter Cordes Nov 22 '17 at 06:12
  • @PeterCordes I am in CPL = 3, so that explains the XSAVES errors. I am also not checking the CR4, is it possible to read CR4 in CPL = 3? – gnzlbg Nov 22 '17 at 15:21
  • 1
    @PeterCordes In a nutshell I am trying to fix issue https://github.com/rust-lang-nursery/stdsimd/issues/209 in `coresimd` (the bare-metal SIMD component of Rust's core library), and am having a lot of trouble writing useful tests for the xsave intrinsics. I'd really appreciate it if someone more experienced could take a look or stab at it. – gnzlbg Nov 22 '17 at 17:01
  • Oh, you're trying to test bare metal? When x86 boots, SSE and AVX aren't enabled. The OS (or startup code for a freestanding program?) has to set bits in control registers to enable it. This is basically a promise made by the OS that it will save/restore SSE (and AVX) state on context switches. This avoids the situation where user-space could run SSE or AVX instructions but then have their registers silently corrupted. (It also allows lazy FPU/SSE context switching by letting the OS make SSE instructions fault to trigger a state save (Linux uses eager FPU save/restore these days)). – Peter Cordes Nov 22 '17 at 21:44
  • 1
    See http://wiki.osdev.org/SSE for the relevant control-register bits for SSE and AVX. If you want to properly test that part of *bare metal* SIMD, you're going to need an emulator to make sure your runtime startup code enables SSE, AVX, and AVX512 instructions. I don't think SDE has a bare-metal feature, so maybe try BOCHS? That will also let you run tests in ring 0. Other tests can run outside the emulator (for performance reasons, or just so they can still work without that dependency) – Peter Cordes Nov 22 '17 at 21:45
  • If I have some spare time to get into it, I'll take a look at that github issue. But I probably don't have time to get into a new project; I still have stuff I want to finish on other projects first, sorry. – Peter Cordes Nov 22 '17 at 21:50
  • Thanks, I will take a look at BOCHS ! – gnzlbg Nov 22 '17 at 22:35

0 Answers0