Independent native GPU discovery checks

The production code in Source/XFESystem.NativeKernel/GpuHardwareBridge.cs is called by Kernel.Main after the actual framebuffer check and before thread initialization. It scans PCI segment zero, records up to eight NVIDIA display functions, and exposes integer-only xfe_gpu_discovery_info(uint) and xfe_gpu_discovery_record(uint, NativeGpuDeviceDiscovery*, uint) exports. The record and BAR ABI sizes are 272 and 32 bytes, respectively; version is 1. No ABI field grants permission to execute GPU commands or map an aperture.

The probe reads conventional PCI configuration through the existing IRQ-serialized network PCI read export. It never invokes its configuration-write export. It does not write all ones to BARs, change PCI command bits, reset a GPU, touch a BAR aperture, or replace the firmware framebuffer. BarReads=0 in the log means GPU BAR aperture reads; BAR-register reads in PCI configuration are included in ConfigReads.

Ordinary BAR registers contain base/type but no trustworthy aperture length. Size remains zero unless validated from ReBAR's current supported size or the project's UEFI resource handoff. Each accepted size must match the live base, type, alignment, address width and non-overflowing physical range. Conflicting independent sizes invalidate the BAR. The exact 10DE:2B85 + valid PCIe capability combination is an SM120 candidate, not a CUDA capability test.

Extended config is read only when RSDP/XSDT or RSDT/MCFG ranges and checksums validate against the Limine base6 firmware memory map. An MCFG allocation must be completely covered by explicit Reserved memory, without overlapping RAM, ACPI data or framebuffer entries. Unsupported/missing/unsafe ECAM stays unavailable. Each accepted device maps exactly one read-only UC/NX 4 KiB ECAM page; vendor/class/header/command/BAR configuration must match the conventional read before trusting the extended snapshot. The page is then unmapped. The GPU BARs themselves remain unmapped, including when their sizes are known.

The host check project links the production parser verbatim. Its hardware stubs throw if a hardware path is invoked; the byte fixtures are parser test inputs, never native hardware evidence. It has no package dependencies:

dotnet run --project Tools/IndependentKernel/GpuDiscoveryChecks/GpuDiscoveryChecks.csproj -c Release --artifacts-path build/IndependentKernel/GpuDiscoveryHostArtifacts --no-launch-profile
python Tools/IndependentKernel/TestGpuDiscoveryEvidence.py
# Both checks with fresh logs, before/after source hashes, and Result.json:
python Tools/IndependentKernel/TestGpuHardwareBridge.py

The same host project links the separate production NvidiaBootProbe.cs and tests only its TryRegisterPage geometry method. This later boot routine may sample one published GB202 FSP-status register only after an exact RTX5090 identity and a validated UEFI BAR0 extent. Tests cover unknown/small/misaligned resources, 32/64-bit limits, metadata and memory-map conflicts across the entire aperture. They do not call NvidiaBootProbe.Initialize, map a page, read a register or emulate a completed firmware handshake. Its real guest observation is a separate XFE_NVIDIA_BOOT_PROBE marker after the discovery transaction; GspStarted, ChannelCreated, Cuda and GpuRasterization remain zero.

To integrate actual no-NVIDIA QEMU acceptance after a normal source-bound build, use the real serial log generated by the existing native boot harness:

python Tools/IndependentKernel/GpuDiscoveryEvidence.py --serial build/IndependentKernel/Proof-.../Serial.log --expect-absent --require-firmware-handoff

Or import validate_discovery(serial, expect_absent=True, require_firmware_handoff=True) into TestBoot.py, store its result below the same proof directory, and bind the verifier/test hashes in SourceSnapshot. The verifier requires a complete scan, exact device/BAR record counts, no configuration writes, no BAR aperture use, and no acceleration claims. It keeps GpuExecutionVerified, CudaExecutionVerified and GpuRasterizationVerified false even after successful discovery. Full QEMU/physical boot is a separate parent-coordinated check; these scripts never launch or stop a VM or access host PCI devices.