SDE fails in Linux VM | IsProcessorFeaturePresent interception on Windows

[Wilderness]

SDE 9.24 works for me in a Linux VM, but 9.27 and 9.33 doesn't (tested on VirtualBox, but noticed the same behaviour on Github Actions).

Sample output:

# sde-external-9.33.0-2024-01-07-lin/sde64 -- ping
SDE ERROR: t[iform] == 0

 at (no-file):64 Function (no-func)
A: /tmp_proj/sde_jenkins/workspace/pypl-sde-nightly-master/GitSDE-master-9.33.0-dev-10-g6ddc3c13b/pin/Source/pin/vm_u/vm_signal_impl_unix.cpp: NotifyExit: 1248: assertion failed: _initialized

################################################################################
## STACK TRACE
################################################################################
??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x0002f04e2

LEVEL_VM::VM::Shutdown+0x00000008a at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x000234c0a

LEVEL_VM::VM_SHUTDOWN_MANAGER::CompleteShutdown+0x000000074 at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x000235104

LEVEL_VM::VM_SHUTDOWN_MANAGER::DoShutdown+0x00000007c at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x000239b0c

LEVEL_VM::VM_Shutdown+0x0000000a7 at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x00023ab47

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x0001c88aa

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x00044771a

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x0000e2531

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x00018b7eb

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x0000bfa14

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x00007a7a6

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x00005f4d8

??? at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x00005f8d8

main+0x00000009c at /root/sde-external-9.33.0-2024-01-07-lin/intel64/sde-mix-mt.so+0x0000263ac

LEVEL_INJECTOR::UNIX_INJECTEE::StartTool+0x000000197 at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x0003486a7

LEVEL_INJECTOR::UNIX_INJECTEE::RunMainThreadOnPinStackAttach+0x00000036d at /root/sde-external-9.33.0-2024-01-07-lin/intel64/pinbin+0x00034eadd

Detach Service Count: 1
Pin: pin-3.31-98831-c93ba16fe
Copyright 2002-2024 Intel Corporation.

Aborted (core dumped)

Has anyone successfully gotten newer versions of SDE to run in a Linux VM?

---

On Windows, it seems like the IsProcessorFeaturePresent function isn't intercepted by SDE.

Example:

#include <stdio.h>
#include <Windows.h>

int main(void) {
#define P(f) printf(#f " %d\n", IsProcessorFeaturePresent(f))

	P(PF_SSE3_INSTRUCTIONS_AVAILABLE);

#ifdef PF_SSSE3_INSTRUCTIONS_AVAILABLE  // requires newer Windows SDK
	P(PF_SSSE3_INSTRUCTIONS_AVAILABLE);
	P(PF_SSE4_1_INSTRUCTIONS_AVAILABLE);
	P(PF_SSE4_2_INSTRUCTIONS_AVAILABLE);
	P(PF_AVX_INSTRUCTIONS_AVAILABLE);
	P(PF_AVX2_INSTRUCTIONS_AVAILABLE);
	P(PF_AVX512F_INSTRUCTIONS_AVAILABLE);
#endif

	return 0;
}

Run:

> sde -p4 -- program
PF_SSE3_INSTRUCTIONS_AVAILABLE 1

This is actually problematic on newer msvcrt because memset seems to use IsProcessorFeaturePresent to check for AVX availability, instead of CPUID, which can lead to incorrect detection, resulting in errors like the following.

TID 0 SDE-ERROR: Executed instruction not valid for specified chip (P4PRESCOTT): 0x7fffb5e88080: vinsertf128 ymm0, ymm0, xmm0, 0x1
Image: C:\Windows\System32\msvcrt.dll+0x78080
Function: memset
Instruction bytes are: c4 e3 7d 18 c0 01 

Does anyone know of a workaround to this issue?

[AdyT_Intel]

The Intel SDE team is using various Linux VMs running on HyperV for their internal testing. The problem that you see with running on VirtualBox might be related to the CPUID information provided by the VM that confused the tool. We need more information for fixing the issue.

Regarding you question on Windows. By running with -p4 you are instructing Intel SDE to check if all instructions are legal for Pentium4 CPU. The system libraries in Windows assume that the CPU baseline features are much newer than Pentium4. If you want to only check the executable that it can run on Pentium4, then you should add -chip-check-exe-only to the command line.

[Wilderness]

Thanks for the response AdyT_Intel!

What sort of info are you looking for?

This is VirtualBox 7.0.10 (though the latest version is likely no different) on a Windows 10 x64 host and Debian 12 x64 guest. If it is useful, the /proc/cpuinfo from the guest for the first core:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 151
model name      : 12th Gen Intel(R) Core(TM) i7-12700K
stepping        : 2
cpu MHz         : 3609.606
cache size      : 25600 KB
physical id     : 0
siblings        : 6
core id         : 0
cpu cores       : 6
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 22
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase bmi1 avx2 bmi2 invpcid rdseed clflushopt md_clear flush_l1d arch_capabilities
bugs            : spectre_v1 spectre_v2 spec_store_bypass swapgs
bogomips        : 7219.21
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

Thanks for the tip about the -chip-check-exe-only - wasn't aware of that!

The example was to demonstrate that reliance on IsProcessorFeaturePresent may be problematic when testing in SDE. P4 doesn't support SSE3, yet it's shown as available in the sample program above when run in SDE with -p4.

---

@AdyT_Intel wrote:

The system libraries in Windows assume that the CPU baseline features are much newer than Pentium4.

---

That's not entirely correct - the C runtime assumes a SSE2 baseline, so should work on P4. The problem is that it checks for AVX capability via IsProcessorFeaturePresent, which isn't intercepted by SDE, so MSVCRT will assume the host CPU's capabilities regardless of what SDE reports via CPUID.

[AdyT_Intel · Accepted solution]

Hello,

I looked at the features presented in your /proc/cpuinfo and I see a clear mismatch. It say that it has AVX2 instructions but it doesn't have the FMA feature (which were introduced together) . This might confuse Intel SDE to initialize its internal data structure in the wrong way and therefore, hit this assertion.

Regarding the IsProcessorFeaturePresent question, I read a bit about it and I found that it is similar to Linux /proc/cpuinfo in the sense that it exposes the kernel supported processor features and therefore it is not based on the emulation of CPUID instruction. You are correct that Intel SDE does not intercept the calls to IsProcessorFeaturePresent or to the KUSER_SHARED_DATA and therefor does not provide the emulated processor features.

Intel SDE emulates the CPUID instruction and therefore only supports applications that query for supported features via the CPUID instruction.

[Wilderness]

---

@AdyT_Intel wrote:

I looked at the features presented in your /proc/cpuinfo and I see a clear mismatch. It say that it has AVX2 instructions but it doesn't have the FMA feature (which were introduced together) . This might confuse Intel SDE to initialize its internal data structure in the wrong way and therefore, hit this assertion.

---

Good observation! From the logs, FMA is detected on the host, but not passed through to the guest. It looks like the feature is commented out in the VirtualBox source code.

Still, if this is the case, it sounds like a bug in SDE - it shouldn't be assuming features without the adequate CPU feature check.

---

@AdyT_Intel wrote:

Intel SDE emulates the CPUID instruction and therefore only supports applications that query for supported features via the CPUID instruction.

---

Thanks for the confirmation.

This could be more problematic, with Microsoft's C runtime now relying on it, though I do think intercepting kernel calls may be a bit out of scope for SDE. For me, -chip-check-exe-only is sufficient, though it might not be for some others.