Guest environment for 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: <VGA-compatible display> 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).