# guest environment evidence (DF-3642 / DF-3643)

Captured 2026-09-15 via `dfbsd-qemu/vm.sh run_root`:

```
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
---
kldstat | grep -i "em\|igb"          -> (empty; not a separate module)
kldload if_em                          -> kldload: can't load if_em: module already loaded or in kernel
                                       => em(4)/ig_hal COMPILED INTO X86_64_GENERIC KERNEL
pciconf -l (network-relevant):
  virtio_pci0@pci0:0:3:0: class=0x020000 card=0x00011af4 chip=0x10001af4  <- NIC is virtio
  hostb0 0x12378086 / isab1 0x70008086 / atapci0 0x70108086 / none0 0x71138086  <- i440FX bridge, NOT e1000 LAN
ifconfig -l: vtnet0 lo0
dmesg: no em[0-9]/ich8 messages
```

## Meaning

1. The audited file `sys/dev/netif/ig_hal/e1000_ich8lan.c` is **live kernel code** on this
   guest (statically linked into GENERIC), and on every real Intel-PCH machine booted from
   `X86_64_GENERIC` it drives the on-board ICH8/PCH GbE MAC (e.g. every I217/I218/I219).
2. This guest presents **no Intel GbE MAC**: probe of `em_attach` never matches, so none of
   the audited code paths (NVM flash cycles, PHY workarounds, link config) execute here.
3. Therefore runtime reproduction of both findings on this guest is impossible; both are
   verified at source level (see trace.log) and their logic is additionally confirmed to be
   byte-identical in FreeBSD HEAD upstream (i.e. vendor-inherited, not a DragonFly sync
   typo).