Guest environment for DF-5067 / DF-5068 / DF-5069 (sys/dev/drm/amd/powerplay/hwmgr/pp_psm.c) ========================================================================================== Captured: 2026-09-26 (pass-2 audit run, df-bsd-reviewer) uname -a ------- DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 PCI display devices (pciconf -l) -------------------------------- vgapci0@pci0:0:2:0: class=0x030000 card=0x11001af4 chip=0x11111234 rev=0x02 hdr=0x00 -> vendor 0x1234/device 0x1111 = QEMU Bochs/VBE std VGA. NOT an AMD GPU. dmesg (display) --------------- vgapci0: mem 0xfebd0000-0xfebd0fff,0xfd000000-0xfdffffff at device 2.0 on pci0 vgapci0: Boot video device -> no amdgpu/radeon/inteldrm attach; no powerplay initialization ever runs. /dev/dri -------- ls: /dev/dri: No such file or directory -> no DRM device nodes exist; no unprivileged (or privileged) user can reach any amdgpu/i915 ioctl on this guest. Kernel modules on disk ---------------------- /boot/kernel/amdgpu.ko, drm.ko, i915.ko, radeon.ko exist (loadable modules), but with no AMD/Intel display hardware present, amdgpu.ko can never attach, so psm_init_power_state_table()/power_state_management()/psm_fini_power_state_table() (pp_psm.c) can never execute on this guest. Conclusion ---------- All three findings in pp_psm.c are hardware-gated (require an AMD GPU whose VBIOS / powerplay table drives the psm state machine). The single-tenant QEMU audit guest has no such hardware; the affected code path is unreachable at runtime here, so no live PoC or fix-validation run is possible. Verdicts are "untested" on that documented basis (impact assessed statically, path:line cited in VERDICT.md).