5-level paging support broken on kernels without it enabled

[jseba]

Description

We recently pulled in the 20251103.0 release and this has started hanging containers on machines that have a CPU that reports 5-level paging in CPUID but the kernel doesn't have it enabled. This will likely break on older kernels running on newer CPUs (e.g. enterprise distros) that don't even have 5-level paging in the kernel at all.

Gvisor needs to query the host kernel for 5-level paging support, it's not enough to just look at CPUID for support. If 5-level paging is not enabled in the kernel, /proc/cpuinfo will report <52 bits of physical address space, even when CPUID reports 52. This will also cause mmap to fail when trying to map these higher addresses into KVM.

Also, why would gvisor hang when this mmap fails? I had to SIGTERM the sandbox process to get it to dump the error log.

gvisor error log

physical_map.go:177] Filling address space failed (VirtualAddressBits=57 PhysicalAddressBits=52 vSize=0x100000000000000 pSize=0xfffff00000000 faultBlockSize=0x80000000 required=0xf0000400000000 filled=0x7fffb30e6000); last mmap errno: cannot allocate memory; VMAs:

/proc/cpuinfo for an AMD 9965

jseba@748m13:~$ cat /proc/cpuinfo | head -n50
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 26
model           : 17
model name      : AMD EPYC 9965 192-Core Processor
stepping        : 0
microcode       : 0xb10100f
cpu MHz         : 3750.997
cache size      : 1024 KB
physical id     : 0
siblings        : 384
core id         : 0
cpu cores       : 192
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 16
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect movdiri movdir64b overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d sev sev_es debug_swap amd_lbr_pmc_freeze
bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass srso vmscape
bogomips        : 4493.34
TLB size        : 192 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 57 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

Steps to reproduce

1. Run a KVM container on a host kernel that does not have 5-level paging enabled and a CPU that does support it
2. Gvisor hangs

runsc version

release-20251103.0

docker version (if using docker)

uname

6.12.58

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

[ayushr2]

cc @tranji-cloud

[ayushr2]

@jseba What release were you using before? Here are some relevant commits which added 5-level page table support for KVM, but they were made in August:

• 1826627
• 05bd51b
• 49a6cc3

So were you using a release older than that?

[jseba]

we were on release-20250820.0, which does not have those commits

[tranji-cloud]

@jseba Apologies for the inconvenience here. Good catch on the querying the host for 5-lvl page support.

I have implemented a fix in PR #12310 to handle this case. If you would like, you can test it on your specific hardware.

Also, why would gvisor hang when this mmap fails? I had to SIGTERM the sandbox process to get it to dump the error log.

This behavior is unexpected; gVisor should have panicked indicating that fillAddressSpace failed rather than hanging. I haven't been able to reproduce the hang locally just yet. So I need a little more time to audit the error handling path. I will follow up with you once I finish the review.