Memo – Deriving QEMU CPU Flags from /proc/cpuinfo

When enabling nested virtualization (e.g., VMware Workstation inside a Proxmox VM), you may need to explicitly pass CPU flags to the guest. Proxmox does not always expose all hardware capabilities by default.

1. Inspect the host CPU capabilities

On the Proxmox host:

```
cat /proc/cpuinfo
```

Look at the two sections:
	•	flags → general CPU instruction set features.
	•	vmx flags (Intel) or svm flags (AMD) → virtualization-specific capabilities.

Example from the host (Intel):

flags       : ... ssse3 sse4_1 sse4_2 aes xsave avx avx2 fma bmi1 bmi2 ...
vmx flags   : ... ept vpid unrestricted_guest ...


⸻

2. Identify features relevant for nested virtualization

From vmx flags pick the virtualization extensions required by VMware/VirtualBox:
	•	+vmx → base Intel VT-x.
	•	+ept, +unrestricted_guest, +vpid → needed for running 64-bit nested guests.

From flags pick common instruction set extensions that modern hypervisors expect:
	•	SIMD: +ssse3, +sse4.1, +sse4.2
	•	Crypto: +aes
	•	Vector ops: +avx, +avx2, +fma
	•	State save/restore: +xsave, +xsaveopt, +xsavec, +xsaves, +xgetbv1
	•	Performance: +bmi1, +bmi2, +invtsc, +pdpe1gb, +tsc-deadline

⸻

3. Translate into QEMU arguments

Proxmox’s cpu: directive does not always accept adding +vmx.
Instead, use the args: directive to override QEMU’s -cpu line:

args: -cpu host,+vmx,+ssse3,+sse4.1,+sse4.2,+aes,+xsave,+xsaveopt,+xsavec,+xgetbv1,+xsaves,+avx,+avx2,+fma,+bmi1,+bmi2,+invtsc,+pdpe1gb,+tsc-deadline

This ensures the guest OS and nested hypervisors see the same set of CPU capabilities that exist on the host.

⸻

4. Verify inside the guest

Inside the Windows or Linux guest, confirm the flags are visible:
	•	On Linux:

cat /proc/cpuinfo | grep -E "vmx|avx|fma|sse4"


	•	On Windows: use Coreinfo.exe (Sysinternals) or CPU-Z to check feature availability.

If vmx (Intel VT-x) or svm (AMD-V) is exposed, nested hypervisors like VMware Workstation can run.

