Great questions—let’s break this down step by step, since accurate cycle counting in KVM/QEMU can be tricky but totally doable with the right configurations.

No, RDTSCP support isn’t a universal gap in QEMU. The issue you’re seeing is almost certainly a configuration problem, not an inherent limitation of QEMU itself. Here’s why and how to fix it:

• Host CPU passthrough: If you launch QEMU with -cpu host, it will directly expose your host’s CPU features (including RDTSCP, since your host supports it) to the guest. This is the simplest way to get RDTSCP working, as KVM will pass through the instruction directly to the hardware.
• Custom CPU configurations: If you’re using a predefined CPU model like qemu64, RDTSCP isn’t enabled by default. You can explicitly add it with the +rdtscp flag, e.g.:

  qemu-system-x86_64 -enable-kvm -cpu qemu64,+rdtscp,... [other options]
  

• Older QEMU versions: Very old QEMU releases (pre-2.12, circa 2018) had limited RDTSCP support, but any modern version (3.x+) fully supports it when configured correctly.

VM exits for RDTSC/RDTSCP can kill measurement accuracy because each exit adds significant overhead (hundreds to thousands of cycles). Here’s how to handle this:

How to detect if RDTSC/RDTSCP is causing VM exits #

• Use perf on the host: Run the following commands to capture KVM exit statistics:

  perf kvm stat record -a
  # Let your guest run the code using RDTSC/RDTSCP, then stop the recording with Ctrl+C
  perf kvm stat report
  

  Look for exit reasons labeled RDTSC or RDTSCP in the output. If the count is high (matching how many times you called the instructions), you’re hitting VM exits.
• QEMU debug logging: Add the -d kvm flag when launching QEMU, then check the log output for lines like:

  KVM: exit reason 12 (RDTSC)
  

  This confirms that RDTSC is triggering exits.

How to avoid VM exits for RDTSC/RDTSCP #

• Stick to CPU passthrough (-cpu host): This is the most reliable way to eliminate RDTSC/RDTSCP exits. When using -cpu host, KVM allows the guest to execute these instructions directly on the host CPU without trapping to the hypervisor.
• Use host-model CPU: If -cpu host causes compatibility issues (e.g., migrating the guest to another host), use -cpu host-model instead. It mimics your host’s CPU features while maintaining better compatibility, and still enables direct RDTSC/RDTSCP execution.
• Verify TSC synchronization: Ensure the guest’s TSC is synchronized with the host. You can set the RTC to use the host clock with:

  -rtc base=utc,clock=host
  

  Also, configure the guest OS to use TSC as its primary clock source (add clock=tsc to the guest’s GRUB kernel parameters) to reduce kernel-level interference with cycle counting.
• Optimize serialization: Intel’s recommendation to use cpuid before/after rdtsc to serialize instructions is valid, but cpuid can also trigger VM exits if not configured properly. With -cpu host, cpuid is passed through directly, so it won’t cause exits. If you must use a custom CPU model, add +cpuid (though most models include this by default) to keep serialization overhead low.
• Average multiple measurements: Even with perfect configs, occasional anomalies can happen. Run your cycle-counting code 1000+ times and take the average to smooth out any rare exit overhead or system noise.

内容的提问来源于stack exchange，提问作者Peter