Return to

Possible solution for Red dead redemption 2 in a VM

If anybody is interested, I may have found a possible fix for starting rdr2 in QEMU.

If you have the issue where the game crashes when entering settings or story mode with no error message, this may help.

It seems that if you remove the BOCHS and BXPC strings from the acpi table, the game works (at least on my VM)!

I also changed the smbios and removed any references to QEMU, don’t know if this helps but it won’t hurt.

Changing the smbios is easy, can be done with qemu arguments. Changing the acpi tables is not that easy. There is the argument “acpitable” to add a new acpi table, but I couldn’t find how to easily modify the default acpi tables.

Unfortunately the only way I know to change the default acpi tables is to patch and build your own QEMU.

I have created a patched QEMU repository here which is based on v5.1.0, but since the patch is so trivial you should be able to rebase it on any version.

One more problem is that Windows 10 seems to do some kind of acpi tables caching, so even if you change the values in the tables, they are not refreshed. I noticed that by changing the ovmf firmware file to another file that is different, it forces Windows to reload the table. You can use the tool from here to check the values of the acpi tables, if you still see BOCHS and/or BXPC then the tables were not refreshed. If somebody knows of a better way to disable this stupid caching let me know.

If you want to use a different edk2 firmware which should force Windows to refresh the tables, you can use the one I patched to remove a string that could also expose that windows is running in a VM. You don’t need this change, RDR2 should start just with modified acpi tables. You can get it here

Build QEMU:

git clone [email protected]:virt-hide/qemu.git
cd qemu
git checkout hide-qemu
git submodule init
git submodule update --recursive
#I build qemu in bin/native
mkdir -p bin/native
cd bin/native
../../configure --prefix=<Somewhere you would like to have qemu installed> --target-list=x86_64-softmmu
make -j16
make install

Build OVMF:

git clone
cd edk2
git checkout hide-edk2
make ARCH=X64 -C BaseTools
. ./
mkdir -p ovmf
cp Build/OvmfX64/*/FV/OVMF_*.fd ovmf/

You can easily change the emulator to your own in libvirt under node :

<emulator><path to qemu executable>/qemu-system-x86_64</emulator>

The SMBIOS can be cleaned up in libvirt like this:

In node add:

<smbios mode='host'/>

But this is not enough, some QEMU string are still present in SMBIOS, so I also changed some other values:

In qemu:commandline node add:

    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=2,manufacturer=ASRock,product=X470 Taichi,version=AM4,serial=S4M88119'/>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=4,manufacturer=AMD,version=1000'/>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=17,manufacturer=Micron'/>

SMBIOS changes may be unnecessary, I didn’t test without them. Also, I use kvm hidden state on, don’t know if it’s necessary.


I have RDR2 on my pile of shame and did not know that it is a problem to run this in a VM. If this is the case I just won’t play it, this is way to much hassle to fix a broken game. Only thing I regret is I can not return it anymore.

I doubt this is an accidental bug, it looks intentional to me.

I though it is a singleplayer only game so it is not clear to me what they gain by blocking virtualized environments, but I also agree that this is indeed more plausible this is intentional that perticular game having weird issues. Anyway, if I can’t play it their future productions will not be bought.