[sbates130272]

Summary

• GPU-initiated NVMe Key-Value Store/Retrieve (xio-tester nvme-ep --kv-op store/retrieve) running on a rocjitsu emulated gfx1250 GPU against an SPDK
  vfio-user KV controller via the pci-mmio-bridge doorbell relay. End-to-end
  confirmed: GPU kernel writes ring command → QEMU bridge dispatches doorbell
  write → SPDK processes SQE → GPU kernel receives CQE.

• pci-mmio-bridge shadow ring fixes for the rocjitsu flat-aperture memory
  model: allocate the ring via mmap with a guard page to prevent rocjitsu's
  MAP_FIXED registration from corrupting glibc's memalign chunk header; use
  a four-step HI=0→LO=0→HI=new→LO=new commit sequence for the override-GPA
  config register to avoid transiently polling live kernel RAM; clean up the
  ring and clear the override on exit so QEMU stops polling freed pages between
  runs.

• Three new VM CI workflows exercising the full emulated stack on GitHub
  Actions runners (no physical hardware required):

  • test-vm-nvme — nvme-ep LBA path, QEMU-emulated NVMe disk (--nvme 1)
  • test-vm-nvme-kv — nvme-ep KV path, SPDK vfio-user controller +
    pci-mmio-bridge (bumped image pins to Oct 20; QEMU image held pending the
    LO-as-commit fix in the sbates fork)
  • test-vm-rdma — rdma-ep ionic loopback, rocm-ernic vfio-user NIC

Caveats

• The QEMU sbates-fork image requires one additional fix in
  pci_mmio_bridge_config_write: the LO register (offset 0x50) must be the
  sole commit trigger for the 64-bit override GPA; the current image fires on
  both HI and LO writes, causing a transient intermediate poll of high guest
  RAM. A follow-up image publish is needed before test-vm-nvme-kv CI can
  pass reliably.

• LD_PRELOAD=libjemalloc.so.2 is injected by run-nvme-kv-test.sh when
  XIO_FORCE_PCI_MMIO_BRIDGE=1 to work around a ROCm 10.x HIP runtime
  overflow in hipHostRegister's internal tracking struct that corrupts
  glibc's heap before the ring write reaches QEMU.

🤖 Generated with Claude Code