My goal for these posts are simple: people should be able to enjoy the games they legitimately own in whatever computing environment they prefer. Be it for security isolation, OS preference, or hardware constraints.

Disclaimer: This post is purely educational and explores the technical mechanisms behind CPU timing detection. I am not encouraging anyone to bypass anti-cheat systems. Attempting to circumvent these protections typically results in being kicked from games when caught but they may change their tune at any-point and thus result in account bans. This information is provided to help people understand the technical challenges of VM gaming and the reality that many games can indeed run in virtual machines despite common misconceptions.

The "Impossible" VM Gaming Myth

Following my previous article on EA Javelin, I received numerous replies both here and elsewhere claiming that games with RDTSC timing checks simply "cannot run in VMs" or "results in immediate bans" and that virtualization is fundamentally incompatible with modern anti-cheat systems.

This isn't true. While challenging, the technical barriers can be understood and, addressed without reprocussions.

What Are RDTSC Timing Checks?

RDTSC (Read Time Stamp Counter) timing checks are one of the most sophisticated VM detection methods used by modern games. Unlike simple CPUID checks that look for hypervisor signatures, timing checks measure the actual performance characteristics of CPU instructions to detect virtualization overhead.

The Detection Mechanism

Here's the actual code pattern that games like those using BattlEye and Easy Anti-Cheat employ:

static inline unsigned long long rdtsc_diff_vmexit() { unsigned long long ret, ret2; unsigned eax, edx; // Get initial timestamp __asm__ volatile("rdtsc" : "=a" (eax), "=d" (edx)); ret = ((unsigned long long)eax) | (((unsigned long long)edx) << 32); // Run an instruction that will cause the VM to have to pass back to the host CPU natively. CPUID is an example of this __asm__ volatile("cpuid" : /* no output */ : "a"(0x00)); // Get timestamp after VM exit __asm__ volatile("rdtsc" : "=a" (eax), "=d" (edx)); ret2 = ((unsigned long long)eax) | (((unsigned long long)edx) << 32); return ret2 - ret; } int detect_virtualization() { unsigned long long avg = 0; // Run test multiple times for accuracy (10 times in this example) for (int i = 0; i < 10; ++i) { avg += rdtsc_diff_vmexit(); Sleep(500); } avg = avg / 10; // Real hardware: <750 cycles, VM: 1200+ cycles return (avg < 750 && avg > 0) ? 0 : 1; } Why This Works

On Real Hardware:

• CPUID executes natively in ~50-200 CPU cycles (This range is to accommodate for different CPUs)
• Timing is consistent and predictable
• Average difference stays well under 750 cycles which they use as a bar to flag VMs.

In Virtual Machines:

• CPUID causes expensive VM exit (guest → hypervisor transition)
• KVM must process the CPUID instruction in host context
• VM exit + processing + VM entry overhead: 1,200-2,000+ cycles
• The timing difference immediately reveals virtualization

This is fundamentally different from hiding CPU vendor strings or disabling hypervisor CPUID bits. As those are flat commands, this is a dynamic, runtime check I.e it's measuring the actual computational overhead that virtualization creates.

A Working Solution: kvm-rdtsc-hack

While I won't detail how to bypass EA's Javelin anti-cheat specifically (and this will not work on it anyways), there are legitimate tools for addressing RDTSC timing detection in general VM scenarios.

The kvm-rdtsc-hack kernel module by h33p provides a working solution for many RDTSC-based detection systems that use the CPUID has the testing method.(NOTE THIS IS BECOMING LESS AND LESS COMMON):

# Clone and build the module git clone https://github.com/h33p/kvm-rdtsc-hack cd kvm-rdtsc-hack make # Load with appropriate timing offset sudo insmod kvm-rdtsc-hack.ko constant_tsc_offset=1600

With the module does is intercepts KVM's RDTSC handling and provides fake timing values:

// Core logic from the actual module source static void vcpu_pre_run(struct kvm_vcpu *vcpu) { u64 cur_tsc, off, tsc_offset, new_tsc_offset; struct vcpu_offset_info *off_info; tsc_offset = vcpu->arch.l1_tsc_offset; off_info = get_cpu_offset_info(vcpu); if (off_info->called_cpuid) { // Calculate fake timing to mimic real hardware cur_tsc = rdtsc(); off = -kvm_scale_tsc(vcpu, constant_tsc_offset + cur_tsc - off_info->vmexit_tsc); new_tsc_offset += off; off_info->temp_offset += off; } // Apply the fake offset to make VM exits appear faster if (tsc_offset ^ new_tsc_offset) vcpu->arch.tsc_offset = kvm_x86_ops.write_l1_tsc_offset(vcpu, new_tsc_offset); }

Key Insight: Instead of trying to make VM exits faster (hard to do but a better approach), it manipulates the TSC values that the guest sees, making VM exits appear to take only ~200-400 cycles instead of the real 1,200+ cycles.

Timing Offset Values: When setting your timing remember that Higher values = lower apparent timing, but risk backwards time progression as such on average you want to set it appropriately for your CPU:

• Intel systems: typically 1000-1200
• AMD Ryzen: typically 1400-1800

Testing Your Setup:

# Use pafish or similar detection tool ./pafish # Should show: [PASS] RDTSC VM exit timing check Limitations and Reality Check This Approach Has Limits

• EA Javelin: Uses additional detection vectors beyond RDTSC checks that this method doesn't address
• Performance Impact: RDTSC interception adds measurable overhead (~2-5%)
• Maintenance: Kernel modules need updates for new kernel versions

EA's Javelin anti-cheat implements multiple detection layers so this alone would never work:

1. RDTSC timing checks (what this method addresses)
2. Hardware performance counter analysis via APERF/MPERF MSRs
3. Cache timing attacks measuring L1/L2/L3 cache access patterns
4. Memory access pattern detection for VM memory management signatures
5. System call timing analysis measuring syscall overhead differences

The kvm-rdtsc-hack module only addresses layer 1. EA Javelin's additional detection vectors remain unaffected, which is why this specific approach doesn't work against current EA titles.

submitted by /u/KstrlWorks
[link] [comments]

Farlight 84 has relaunched with a massive new upgrade that brings a first-person mode, but it's sadly now broken on Linux, SteamOS / Steam Deck.

.

Read the full article on GamingOnLinux.

7950x3d, 128gb ram, 5090

Yes, I am aware of the DX12 nvidia bug, but still - all settings maxed.

- DLSS off: 45-50fps
- DLSS Quality: 65 fps

...on a 5090.

The frame gen toggle seems broken, must be a game issue because toggling it does nothing and there is a steam community post about here: https://steamcommunity.com/app/1941540/discussions/3/596282483724649664/

submitted by /u/turbochamp
[link] [comments]

In Terra Nil you're tasked with restoring life to barren environments and things have begun heating up in the new free update.

.

Read the full article on GamingOnLinux.

Need more games? Here's all that's coming to Prime Gaming in August 2025. An easy way to add more games to your library across Linux, SteamOS and Steam Deck.

.

Read the full article on GamingOnLinux.

I have tried without success to use gamescope with my nvidia card on 570 drivers. I'm trying because I want HDR and hoping gamescope can help since I use mint cinnamon, which uses x11.

From a TTY, not within cinnamon, I tried quite a few switches but even the simplest:
gamescope -- steam -gamepadui
results in this (warning - strong flashing):

https://reddit.com/link/1mk9kyd/video/sw5j5d6aenhf1/player

i have the nvidia-drm.modeset=1 enabled in my grub config, and have tried -e, -f, -r 60, have also tried these before the gamescope command:
DXVK_HDR=1 ENABLE_HDR_WSI=1 ENABLE_GAMESCOPE_WSI=1
ENABLE_GAMESCOPE_WSI=0

and have added -steamos to the steam command.

not even gamescope -- glxgears looks right - also strong flickering.

nvidia 570.169
kernel 6.14.0-27-generic
gamescope from july 29, commit 1faf7acd90f960b8e6c816bfea15f699b70527f9

I just followed the build instructions on github, didn't change any settings. Very open to the idea that I screwed something up while installing one of the bajillion dependencies.

submitted by /u/plumber_craic
[link] [comments]

Just like what happened with DOOM + DOOM II, Nightdive Studios have remastered the classics Heretic + Hexen as one bundle with new content.

.

Read the full article on GamingOnLinux.

submitted by /u/_Zebulah
[link] [comments]

(System Information at the end. TLDR Sys. Info: Ryzen 9 7900X, RTX 2080 Ti (570.169), 64 GiB RAM, Nobara 42, KDE Plasma.)

Hello! I recently got a good deal on Assassin's Creed Shadows, which ended up being through Ubisoft Connect. To play this on my Nobara Linux 42 machine, I used Lutris, which worked fine once I removed the default DLL override Lutris put on for it. The game opened, the intro videos played, I was able to create a new save, but as soon as I got into a portion of the game that actually had the game's world in it (in this case, the first cutscene with Yasuke), I froze within the first thirty seconds and it never resumed even after two hours of waiting. This happened multiple times despite changing in-game settings like setting all graphics to Very Low, disabling the Upscaling and Frame Generation settings, etc.

When trying to figure this out by looking online I found two posts on this sub-reddit (link1, link2) from four months ago that pointed me towards using Pyroveil. I did this, and I had no change with regard to my problem. I got in contact with someone from the two threads that had gotten their's working with a similar setup, and they even said that the newer drivers (570.153.02 and later) don't seem to need the Pyroveil fix to play without the issue.

Through Lutris, I've tried GE-Proton (Latest), GE-Proton 8-25, GE-Proton 9-26, GE-Proton 9-27, GE-Proton 10-10, Proton (Experimental), and wine-tkg-valve-exp-bleeding-experimental.bleeding.edge.10.0.226640.20250804. All of these either had the same freezing issue, or didn't even open Ubisoft Connect properly. Using advice from various places on the web for similar issues with other games, I disabled Esync, Fsync, and Feral GameMode in Lutris, and tested various environmental variables in Lutris including DXVK_ENABLE_NVAPI=1 and DXVK_SYNC=0, and I used MangoHUD to limit my fps to 30.

At that point, I was actually able to play without freezing, but only at 30 fps. I raised this to 60 and got a freeze, lowered it to 45 and got a freeze, lowered it to 42 and no longer froze. I can deal with this if I have to, but I'd rather play the game at a higher frame-rate if I can, since I think my GPU should be able to (I could be wrong, it's "old" now, I know).

I also tried playing the game on both my Steam Deck OLED and Framework 16 w/ GPU module (Fedora Linux 42) and the game worked without issue on both. Because of this, I figured it could be an issue with my drivers or GPU. I'm relatively new to Lutris, though, so I don't know.

I did also try playing this through Steam via installing Ubi. Connect as a non-Steam game, then adding the UbisoftConnect.exe executable as a non-Steam game, too, and playing through that but it also had the same freezing issue on Proton Experimental and GE-Proton 10-10. By this point today, I've been locked out by Ubisoft's DRM for the third time in the last three days, so I'll have to wait for another 24 hours or so before I can even launch the game again.

I should note that I did play the game on my Steam Deck and Framework 16 for a while to progress before trying on my desktop again later to ensure it wasn't an issue with the first cutscene somehow. Despite this, I continue to freeze on the desktop when the game world loads or when the benchmark begins.

As far as I've been able to tell from MangoHUD and nvtop, my GPU and CPU temps have been fine. I have, however noticed that every time I freeze MangoHUD reports my GPU utilization at 95%. Any help on this issue would be greatly appreciated. This is the only game I've had a serious issue playing on Linux (that wasn't due to Anti-Cheat).

I didn't save any logs from Lutris or Proton before I got locked out for 24 hours today by Ubisoft's Denuvo DRM. If I haven't found a solution by the time I get unlocked, I'll update the post with some logs here.

PS: I tried to adhere to the sub-reddit's guide on writing tech-support posts as best I could. If there is something you think could help me improve this request, please let me know and I'll do my best to update it.

System Information

• Nobara Linux 42
• KDE Plasma Version 6.4.3
• Kernel 6.15.8-200.nobara.fc42.x86_64 (64-bit)
• Graphics Platform: Wayland
• CPU: AMD Ryzen 9 7900X 12-Core Processor
• GPU: NVIDIA GeForce RTX 2080 Ti
• GPU Driver: 570.169
• 64 GiB of RAM
• Mesa version: 25.1.7

The Lutris version I've been using is 0.5.19 via the nobara-updates repo.

The Steam version I used is Steam Version: 1751405894, also from the nobara-updates repo.

submitted by /u/VenatorPrinceps
[link] [comments]

Hey I decided to download Linux mint on my old ASUS X55C with an i3-2328m and 8 GB of RAM to try it I can play the latest Minecraft Java version with an average 40 FPS, on Windows 10/11 I could only play 1.16.5 with 30 FPS I wanted to ask if there is a better Linux Distribution for my old Laptop

submitted by /u/djdkxnxldbxkf
[link] [comments]

submitted by /u/YanderMan
[link] [comments]

https://preview.redd.it/2mqv9hi9zmhf1.png?width=1920&format=png&auto=webp&s=62ac407a678ab53ea6fad1770d1655558c1231af

I can not play on some of the most popular servers on Unturned. Because I use Linux. What is this

submitted by /u/Kapanyel69
[link] [comments]

Hello, im the creator and developer of PULS

PULS is a responsive and feature-rich system monitoring dashboard that runs in your terminal. Its primary goal is to provide a clear, comprehensive, and interactive view of system processes, complemented by a high-level overview of hardware statistics.

Built with Rust, PULS allows you to quickly identify resource-intensive applications on the dashboard, and then instantly dive into a Detailed Process View to inspect the full command, user, environment variables, and more.

For reliability, PULS also features a Safe Mode (--safe), a lightweight diagnostic mode that ensures you can still analyze processes even when your system is under heavy load or if you have a low-end system.

I just released v0.2.0, im waiting for your feedback who tests it, thank you! Here is the GitHub Page: GitHub Link

submitted by /u/word-sys
[link] [comments]

Ever since last night Sober refused to work.
At first it just said that I had disconnected and needed to reconnect but whenever I tried to join any game it would say that, I checked if I was still connected to wifi and I was it was just that Sober wouldn't respond.
I powered down my system and then it told me that i needed files from android which I very much did not have. Then I uninstalled and reinstalled, powered down my system again and when I got back it told me an update was required. I copy pasted the code into terminal, and it successfully uninstalled but as you can see on the left it couldn't reinstall, and when I tried to update flatpak it just told me, "Nothing to do."

submitted by /u/Fast_Cow_7526
[link] [comments]

I wanted to play Honkai Star Rail on my archlinux laptop
well launcher worked out of the box i downloaded HSR and hit start game
the launcher closed, game screen came for a split second and disappeared.

i have checked the logs and encountered these

info: OpenVR: could not open registry key, status 2
info: OpenVR: Failed to locate module
warn: OpenXR: Unable to get required Vulkan Device extensions size
ERROR: ld.so: object 'libgamemodeauto.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file):

these errors came even if i do not hit start game so im not sure these are the errors causing to crash, but i couldnt found anything odd on the log except these

i saw a popular third party launcher but i just didnt use it... do you guys suggest using it?

submitted by /u/Itchy-Stock-6530
[link] [comments]

I have connected my GOG account to play a newly purchased game (but old title) on my ubuntu build, but said game doesn’t appear. I refreshed and restarted everything, waited a week and still nothing.
How can I fix this issue?

submitted by /u/RedN00ble
[link] [comments]

submitted by /u/ygames1914A
[link] [comments]

This latest Warner Bros. Games Humble Bundle looks to be great value with lots of games for a small price and good overall Linux compatibility.

.

Read the full article on GamingOnLinux.

My Linux Steam library is on an SSD that is failing. (5000+ Non-correctable errors according to smarttools and some ATA hardware errors when trying to play some games.) The Steam library is NOT the default one in my home directory. If I replace the drive and recreate an empty directory with the same path and name as the old Steam Library, other than needing to re-install games, what bad things will happen? Any suggestions?

submitted by /u/Symbolic_Link
[link] [comments]

Casebook 1899 - The Leipzig Murders is a richly atmospheric, retro-inspired point-and-click adventure set in Leipzig, Germany at the dawn of the 20th century.

.

Read the full article on GamingOnLinux.