2

What I want to achieve is disabling SSE4.2 instruction set for CPU which VirtualBox emulated for my Linux guest OS for debugging purpose, even though the real CPU support SSE4.2 instruction set on which VirtualBox is based. I referred to the VirtualBox manual page, there are several commands that might be related to this issue:

VBoxManage setextradata "VM name" VBoxInternal/CPUM/SSE4.2 0

The above command didn't work.

VBoxManage list hostcpuids

The above command can be used to dumps the CPUID parameters for the host CPUs. This can be used for a more fine grained analyis of the host's virtualization capabilities. The output is: 

Host CPUIDs:

Leaf no.  EAX      EBX      ECX      EDX
00000000  00000016 756e6547 6c65746e 49656e69
00000001  000906e9 02100800 7ffafbff bfebfbff
00000002  76036301 00f0b6ff 00000000 00c30000
00000003  00000000 00000000 00000000 00000000
00000004  1c004121 01c0003f 0000003f 00000000
00000005  00000040 00000040 00000003 00142120
00000006  000027f7 00000002 00000001 00000000
00000007  00000000 029c6fbf 00000000 00000000
00000008  00000000 00000000 00000000 00000000
00000009  00000000 00000000 00000000 00000000
0000000a  07300804 00000000 00000000 00000603
0000000b  00000001 00000001 00000100 00000004
0000000c  00000000 00000000 00000000 00000000
0000000d  0000001f 00000440 00000440 00000000
0000000e  00000000 00000000 00000000 00000000
0000000f  00000000 00000000 00000000 00000000
00000010  00000000 00000000 00000000 00000000
00000011  00000000 00000000 00000000 00000000
00000012  00000000 00000000 00000000 00000000
00000013  00000000 00000000 00000000 00000000
00000014  00000001 0000000f 00000007 00000000
00000015  00000002 0000011c 00000000 00000000
00000016  00000d48 00000ed8 00000064 00000000
00000017  00000d48 00000ed8 00000064 00000000
80000000  80000008 00000000 00000000 00000000
80000001  00000000 00000000 00000121 2c100800
80000002  65746e49 2952286c 726f4320 4d542865
80000003  35692029 3035372d 50432030 20402055
80000004  30342e33 007a4847 00000000 00000000
80000005  00000000 00000000 00000000 00000000
80000006  00000000 00000000 01006040 00000000
80000007  00000000 00000000 00000000 00000100
80000008  00003027 00000000 00000000 00000000
80000009  00000d48 00000ed8 00000064 00000000

I know the output might be closely related to CPUID X86 instruction, but I still can't figure out what these Leaf no. EAX EBX ECX EDX lines meas. What's the relationship between these lines and the output of CPUID instruction? I think that only by knowing the relationship between these lines and the output of CPUID instruction can we use the following command correctly:

VBoxManage modifyvm --cpuid <leaf> <eax> <ebx> <ecx> <edx>

The above command is the only way I known that might achieve my goal, so, what's the relationship between the output of VBoxManage list hostcpuids, content followed by Leaf no. EAX EBX ECX EDX, and the output of CPUID instruction? How to disable SSE4.2 instruction set for CPU which VirtualBox emulated for my Linux guest OS even though the real CPU support SSE4.2 instruction set on which VirtualBox is based? Will VBoxManage modifyvm --cpuid <leaf> <eax> <ebx> <ecx> <edx> achieve my goal? And If you got any other way to achieve this, please tell me.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
cong
  • 1,105
  • 1
  • 12
  • 29
  • I would be very surprised if it is possible to disable SSE4 at a software level. See also [this](https://superuser.com/questions/244213/how-can-i-check-whether-intels-avx-is-enabled-on-my-computer) and [this](https://software.intel.com/en-us/forums/intel-isa-extensions/topic/508413) discussions. With AVX it is possible to enable/disable OS support, but not CPU support. Note that SSE4 requires no special OS support other than standard SSE support. Note also that the CPU executes the cpu instructions, i.e. the instructions are not emulated by virtualbox. – wim Sep 10 '18 at 19:55
  • Maybe you can attract more attention to your question by adding the `x86` and/or the `simd` tag. – wim Sep 10 '18 at 20:01
  • @wim: `[sse]` is the baseline/generic tag for x86 SIMD that people tend to follow if they don't follow `sse*`. – Peter Cordes Sep 11 '18 at 03:06
  • @wim: it should be possible to modify the CPUID behaviour so it doesn't *report* SSE4.2 as available (because CPUID itself can trigger a VM exit), so you can test the non-SSE4.2 case for runtime dispatching. But as you say, that won't help you test to make sure your software doesn't run any SSE4.2 instructions after detecting they aren't available. For that you'd need BOCHS or qemu for emulating instead of HW virtualization. Or Intel PIN. – Peter Cordes Sep 11 '18 at 03:15
  • @PeterCordes: It's OK if my application executes SSE4.2 instructions or not. I just want to make VirtualBox emulate a CPU without SSE4.2 for debugging purpose. More precisely, I just want to generate a situation that application executes SSE4.2 instructions on a VirtualBox emulated CPU which do not support SSE4.2 instructions. – cong Sep 11 '18 at 03:41
  • 1
    And you want to SSE4.2 instructions to raise a #UD exception (illegal instruction)? Like \@wim and I said, that's not going to happen with HW virtualization. There's no bit you can set with HW virtualization that makes SSE4.2 instructions fault without making all SSE1/2/3 instructions fault as well. You need an emulated CPU like BOCHS/qemu/Intel-Pin. With VBox, I think all you can do is change what CPUID reports. So it's a CPU that still supports SSE4.2 but doesn't tell anyone about it. – Peter Cordes Sep 11 '18 at 03:46
  • @PeterCordes: Yes, I want to raise a illegal instruction exception. And maybe it's OK to disable all the SSE1/2/3/4. Do you know how to achieve this? – cong Sep 11 '18 at 04:37
  • Easiest way would be BOCHS or qemu, or Intel PIN, like I already said. To disable SSE entirely, maybe try just booting with CPUID set to not indicate even SSE1, so the OS won't enable the bits in CR0 and CR4 that make SSE instructions not fault. [How do I enable SSE for my freestanding bootable code?](https://stackoverflow.com/q/31563078). (But that probably only affects instructions that read/write XMM registers, maybe not `prefetch` or `popcnt`. Note that `popcnt` has its own feature bit, separate from SSE4.2.) So you'll want to write some test programs to check. – Peter Cordes Sep 11 '18 at 04:40
  • @PeterCordes Interesting. I didn't know that there were so many CPU emulation tools. – wim Sep 11 '18 at 09:52
  • @PeterCordes, To achieve my debugging purpose, I must make this happen to my VirtualBox, which means I want to generate a VirtualBox without support for SSE4.2 or whole SSE1/2/3/4 to run a application which executes the SSE4.2 instruction. – cong Sep 11 '18 at 11:05
  • @cong: It might be impossible to make `popcnt` and `crc32` fault inside virtualbox, unless you can make it emulate instead of use HW virt. If you just need `pcmpistri xmm, xmm/mem` and other SSE4.2 XMM vector instructions to fault, I think your only hope inside VBox is to completely disable SSE support in CPUID, so the OS (probably) won't enable the control-register bits. – Peter Cordes Sep 11 '18 at 18:31
  • @PeterCordes, So, you mean there is no way to just make crc32 fault without disabling all SSE1/2/3/4...? – cong Sep 12 '18 at 01:32
  • No, I don't think there's any way *at all* to make `crc32` fault on real hardware that supports it (bare metal or hardware virtualization). It doesn't use XMM registers, so I don't expect that not setting those bits in CR0 and CR4 would make it fault. If you want to test your software on a (virtual) x86 that faults on `crc32`, I think you need software emulation, or something like Intel PIN that can dynamically recompile so most code runs natively but the instructions that you want to fault get replaced by a trap instruction. (I think it can do this.) – Peter Cordes Sep 12 '18 at 01:56

1 Answers1

0

I know it has been almost 4 years since the question was posted, but I came across the same problem and eventually found the correct solution:

https://docs.oracle.com/en/virtualization/virtualbox/6.0/admin/sse412passthrough.html

To provide SSE 4.1/SSE 4.2 support to guests, the host CPU has to implement these instruction sets. The instruction sets are exposed to guests by default, but it is possible to disable the instructions for certain guests by using the following commands:

VBoxManage setextradata VM-name VBoxInternal/CPUM/IsaExts/SSE4.1 0

VBoxManage setextradata VM-name VBoxInternal/CPUM/IsaExts/SSE4.2 0

The second line seems to be the answer to your problem. I tested it in my Guest and CPU-Z no longer shows SSE4.2 within the Guest after running the command above in a Host with SSE4.2. The command in the first post is missing "IsaExts".

Johnye
  • 19
  • 2
  • 1
    As [discussed in comments](https://stackoverflow.com/questions/52250249/how-to-change-the-cpu-instruction-set-which-virtualbox-emulated-for-guest-os-li/72169583#comment91484246_52250249), this does *not* make SSE4.x instructions actually fault, it just doesn't report them via CPUID. (The CPUID instruction is always a VMexit, so the VM can set or clear whatever feature bits it wants the guest to see. When guest machine code executes, though, it's still the CPU hardware itself decoding it so SSE4 instructions just work on hardware that natively supports them.) – Peter Cordes May 09 '22 at 09:41
  • 1
    So **it won't help you find usage of SSE4.x instructions in code-paths that run on CPUs that don't report SSE4.x support.** Just so future readers are aware that testing a program this way doesn't prove it won't fault on real CPUs like a Core 2 from 2006-2008 or so, or a Phenom II from 2008-2012. But this is the best VBox or other HW virtualization tools can do, and someone might want this for a different reason, like performance testing of non-SSE4 code-paths on modern CPUs in case that's relevant for some reason. – Peter Cordes May 09 '22 at 09:43
  • Would that also apply to software virtualization? Until 6.0 Vbox did [support](https://web.archive.org/web/20191022191103/http://www.virtualbox.org/manual/ch10.html#swvirt-details) it, even though I'm not exactly sure on how it compared to QEMU's TCG ([bugs](https://lists.gnu.org/archive/html/qemu-discuss/2017-07/msg00041.html) notwithstanding) or VMware's binary translation. – mirh Mar 04 '23 at 14:50