Hardware and Software Matrix - Revision history

WikiBot: Fix repository links: point to the cgit tree URLs

2026-10-12T04:40:57Z

Fix repository links: point to the cgit tree URLs

WikiBot: Carry the site-wide About/licensing message on every page (2026-10-12)

2026-10-12T04:29:47Z

Carry the site-wide About/licensing message on every page (2026-10-12)

← Older revision		Revision as of 04:29, 12 October 2026
Line 1:		Line 1:
			{{About message}}

	= Hardware and Software Matrix =		= Hardware and Software Matrix =

WikiBot: Add page from tracked wiki source (2026 IA update)

2026-10-12T04:22:11Z

Add page from tracked wiki source (2026 IA update)

New page

= Hardware and Software Matrix =

<blockquote>'''Companion summary.''' This page condenses [https://git.vgpu.io/open-iov/blob/master/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — the canonical support matrix: the support ladder, the current status of every host/GPU/guest/hypervisor combination, and what adding a combination requires. The validation process behind every support decision is [https://git.vgpu.io/open-iov/blob/master/docs/06-portability/03-device-validation-and-porting-sequence.md <code>../docs/06-portability/03-device-validation-and-porting-sequence.md</code>]. When this page and the docs tree disagree, the docs tree wins. Front door: [https://git.vgpu.io/open-iov/blob/master/docs/README.md <code>../docs/README.md</code>].</blockquote>

Status: 2026-10-12, tree <code>master @ 2f066727</code>. Tags: <code>[reference]</code> continuously tested, bugs block releases; <code>[supported]</code> tested per release; <code>[experimental]</code> partial or bring-up; <code>[target]</code> designed for, bring-up in progress; <code>[design]</code> design direction, not the current build.

== 1. Support ladder ==

Support means '''tested and documented''', not "should probably work".

{| class="wikitable"
|-
! Level
! Meaning
|-
| '''Reference'''
| continuously tested; bugs block releases
|-
| '''Supported'''
| tested per release; documented workarounds if any
|-
| '''Experimental'''
| known to boot/test partially; may need configuration
|-
| '''Target'''
| architecture designed for it; bring-up in progress
|-
| '''Out of scope'''
| not planned
|}

== 2. Host platforms ==

{| class="wikitable"
|-
! Platform
! Status
! Notes
|-
| x86_64 + NVIDIA Turing (TU104)
| '''Reference'''
| the development hardware (RTX 2080-class); the only Reference platform today
|-
| x86_64 + Ampere / Ada consumer
| '''Target'''
| profile work; expected to be configuration + measurement
|-
| x86_64 + Hopper / datacenter
| '''Target'''
| requires MIG-aware policy for multi-tenancy
|-
| aarch64 + Grace-Hopper (GH200)
| '''Target'''
| host-architecture work in the memory model
|-
| aarch64 + Grace-Blackwell
| '''Target'''
| as above, newer firmware/driver family
|-
| GB10 (DGX Spark, Surface-class RTX laptops)
| '''Target'''
| same architecture; firmware/ROM quirks to be measured
|-
| Other NVIDIA generations
| '''Experimental'''
| bring-up path in the canonical document §5
|}

The design direction is that '''each new host platform should require configuration + verification, not new code''' — not the current state: selection is compile-time today and the module is built for the TU104 profile.

== 3. Guest operating systems ==

{| class="wikitable"
|-
! Guest
! Status
|-
| Linux x86_64 (stock <code>nvidia.ko</code>, CUDA)
| '''Experimental''' — probe, <code>nvidia-smi</code> and the driver-API smoke pass; CE-class copies are forwarded default-off; for GR the guest launch reaches the front-end but no grid has dispatched yet (see [[The Execution Frontier|<code>Execution-Frontier.md</code>]]); no continuous guest testing yet
|-
| Linux aarch64
| '''Target'''
|-
| Windows x86_64 (WDDM driver, CUDA, 3D)
| '''Target'''
|-
| Other Unix (FreeBSD, ...)
| Out of scope until demand
|}

'''Guest rule:''' the guest never contains Open-IOV code — no guest agent, no driver patch, no kernel parameters beyond what the stock driver needs.

== 4. Hypervisors and transports ==

{| class="wikitable"
|-
! Hypervisor
! Status
! Transport
|-
| KVM + QEMU (VFIO mdev)
| '''Reference'''
| VFIO mdev + eventfd IRQ + DMA interface
|-
| libvirt (mdev attach)
| '''Supported'''
| same, via libvirt XML
|-
| Zen / KVM on other device models
| '''Experimental'''
| as above
|-
| Xen (incl. Argo/OpenXT)
| '''Target'''
| Xen device model + event channels
|-
| Qubes OS / Qubes OS Air
| '''Target'''
| compartmentalized VMs; GPU per compartment
|-
| Cloud hypervisor / crosvm
| '''Experimental'''
| VFIO-based; needs testing
|}

The transport boundary — registration, guest-memory access, interrupt injection — is deliberately narrow, so a new transport is small and isolated.

== 5. What portability means today ==

<pre> host architecture GPU family driver/firmware family
┌─────────────────┐ ┌──────────────────┐ ┌────────────────────┐
│ x86_64 │ │ Turing (TU104) │ │ 570.144 (anchor) │
│ aarch64 (Grace) │ │ Ampere / Ada │ │ newer families │
│ GB10-class │ │ Hopper / datac. │ │ (gated, pending │
└────────┬────────┘ └────────┬─────────┘ │ review) │
│ │ └─────────┬──────────┘
└──────────┬──────────┴───────────────────────┘
▼
one combination = hardware profile + version profile
▼
evaluation ladder + evidence → matrix entry:
"hardware X + driver Y + firmware Z, tested at rung R on date D"</pre>

The configuration surface lives in <code>config/</code>: <code>config/hardware/<arch>.yaml</code> (PCI IDs, BARs, memory geometry, engine lists) and <code>config/versions/<driver>.yaml</code> (RPC/control inventories, capability tables).

<blockquote>'''These files are design targets, not live configuration.''' No code reads them today: selection is compile-time and the module is built for the TU104 profile. Treating the YAML surface as authoritative — or claiming "configuration-driven portability" — is aspirational until the profiles are wired into the module's load path. A profile is the ''unit of support''; what is missing is the code that reads the profile files, not the schema.</blockquote>

== 6. Adding a new combination ==

'''New GPU / hardware profile.'''

# Create a hardware profile: PCI IDs, BAR layout and sizes, memory geometry (FB size, BAR windows), engine inventory, interrupt topology, and the register values the guest driver validates during probe.
# Run the five-rung evaluation ladder ([https://git.vgpu.io/open-iov/blob/master/docs/05-operations/01-performance-correctness-security.md <code>../docs/05-operations/01-performance-correctness-security.md</code>]).
# Record the differences; prefer configuration over code.
# Publish the profile, the evidence, and any workarounds.

Firmware-side analysis uses the risc-v-gsp-rm-debugger ([[risc-v-gsp-rm-debugger|<code>Riscv-GSP-RM-Debugger.md</code>]]): first-touch probes and per-pair comparisons classify each difference as profile data or logic before any profile change lands.

'''New firmware version.''' Images are versioned under <code>firmware/<SERIES>-GSP/<VERSION>/</code> with signatures and analysis artifacts; the work is capture, inventory diff, decode against that version's reference, then configuration/handlers and a re-run of the ladder.

'''New driver version.''' Run the trace, diff the RPC/control inventory, add version-keyed handlers, re-run the ladder. Newer driver/firmware families are gated pending review before any work starts.

'''Evidence expectations.''' A combination is entered in the matrix only with the profile fields recorded; the firmware/device pairing verified by hash and version string; every first-touch difference explained as profile or logic; per-pair comparison results with session hashes; the metric table with its reference-capture method and stated fidelity limits; and a supervised physical validation for the support claim. "Tested and documented" is literal: an untested or simulator-only combination stays '''Target''' or '''Experimental'''.

== 7. Anchor versions and engine-list portability ==

The anchor is guest CUDA driver (<code>libcuda</code>) '''570.144''' with GSP firmware '''570.144'''; the host oracle is <code>libcuda</code> '''570.211.01''' with CUDA toolkit '''12.0'''. The versioned surface is the RM ioctl/class/control interface the userspace driver issues — not a stable public API; see [[CUDA Userspace Driver|<code>CUDA-Userspace-Driver.md</code>]].

The engine inventory and its class-list filtering are per-architecture, per-driver data. An earlier gap was concrete: a missing async copy engine blocked context creation until the inventory was completed — which is why it belongs in the hardware profile, validated against the host oracle.

== 8. Known portability risks ==

{| class="wikitable"
|-
! Risk
! Mitigation
|-
| Page-size/cache-attribute differences on aarch64
| keep the memory model abstract; test on Grace early
|-
| Windows driver ROM/VBIOS expectations
| explicit ROM/VBIOS provisioning in the device profile; measured bring-up
|-
| Xen interrupt/memory interfaces differ
| narrow transport interface + Xen backend plan
|-
| Vendor ROMs and laptop firmware variants (GB10/Surface)
| per-device overrides in the profile system
|-
| Driver-family drift (580 and newer)
| version-keyed handlers; matrix-driven testing
|}

== 9. Related documentation ==

* [https://git.vgpu.io/open-iov/blob/master/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — canonical matrix: ladder, status, procedures; the validation process behind every support claim is in [https://git.vgpu.io/open-iov/blob/master/docs/06-portability/03-device-validation-and-porting-sequence.md <code>../docs/06-portability/03-device-validation-and-porting-sequence.md</code>].
* [https://git.vgpu.io/open-iov/blob/master/docs/05-operations/01-performance-correctness-security.md <code>../docs/05-operations/01-performance-correctness-security.md</code>] — the five-rung evaluation ladder and evidence rules.
* [[Project Status|<code>Project-Status.md</code>]] and [[System Overview|<code>System-Overview.md</code>]] — current status and component map.
* [[risc-v-gsp-rm-debugger|<code>Riscv-GSP-RM-Debugger.md</code>]] — firmware-side portability analysis.
* [[HAAEEP and Collaboration|<code>HAAEEP-and-Collaboration.md</code>]] — the edge use case and collaboration models.

← Older revision		Revision as of 04:40, 12 October 2026
Line 3:		Line 3:
	= Hardware and Software Matrix =		= Hardware and Software Matrix =

	<blockquote>'''Companion summary.''' This page condenses [https://git.vgpu.io/open-iov/~~blob/master~~/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — the canonical support matrix: the support ladder, the current status of every host/GPU/guest/hypervisor combination, and what adding a combination requires. The validation process behind every support decision is [https://git.vgpu.io/open-iov/~~blob/master~~/docs/06-portability/03-device-validation-and-porting-sequence.md <code>../docs/06-portability/03-device-validation-and-porting-sequence.md</code>]. When this page and the docs tree disagree, the docs tree wins. Front door: [https://git.vgpu.io/open-iov/~~blob/master~~/docs/README.md <code>../docs/README.md</code>].</blockquote>		<blockquote>'''Companion summary.''' This page condenses [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — the canonical support matrix: the support ladder, the current status of every host/GPU/guest/hypervisor combination, and what adding a combination requires. The validation process behind every support decision is [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/03-device-validation-and-porting-sequence.md <code>../docs/06-portability/03-device-validation-and-porting-sequence.md</code>]. When this page and the docs tree disagree, the docs tree wins. Front door: [https://git.vgpu.io/open-iov.git/tree/docs/README.md <code>../docs/README.md</code>].</blockquote>

	Status: 2026-10-12, tree <code>master @ 2f066727</code>. Tags: <code>[reference]</code> continuously tested, bugs block releases; <code>[supported]</code> tested per release; <code>[experimental]</code> partial or bring-up; <code>[target]</code> designed for, bring-up in progress; <code>[design]</code> design direction, not the current build.		Status: 2026-10-12, tree <code>master @ 2f066727</code>. Tags: <code>[reference]</code> continuously tested, bugs block releases; <code>[supported]</code> tested per release; <code>[experimental]</code> partial or bring-up; <code>[target]</code> designed for, bring-up in progress; <code>[design]</code> design direction, not the current build.
Line 153:		Line 153:

	# Create a hardware profile: PCI IDs, BAR layout and sizes, memory geometry (FB size, BAR windows), engine inventory, interrupt topology, and the register values the guest driver validates during probe.		# Create a hardware profile: PCI IDs, BAR layout and sizes, memory geometry (FB size, BAR windows), engine inventory, interrupt topology, and the register values the guest driver validates during probe.
	# Run the five-rung evaluation ladder ([https://git.vgpu.io/open-iov/~~blob/master~~/docs/05-operations/01-performance-correctness-security.md <code>../docs/05-operations/01-performance-correctness-security.md</code>]).		# Run the five-rung evaluation ladder ([https://git.vgpu.io/open-iov.git/tree/docs/05-operations/01-performance-correctness-security.md <code>../docs/05-operations/01-performance-correctness-security.md</code>]).
	# Record the differences; prefer configuration over code.		# Record the differences; prefer configuration over code.
	# Publish the profile, the evidence, and any workarounds.		# Publish the profile, the evidence, and any workarounds.
Line 196:		Line 196:
	== 9. Related documentation ==		== 9. Related documentation ==

	* [https://git.vgpu.io/open-iov/~~blob/master~~/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — canonical matrix: ladder, status, procedures; the validation process behind every support claim is in [https://git.vgpu.io/open-iov/~~blob/master~~/docs/06-portability/03-device-validation-and-porting-sequence.md <code>../docs/06-portability/03-device-validation-and-porting-sequence.md</code>].		* [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/hardware-software-matrix.md <code>../docs/06-portability/hardware-software-matrix.md</code>] — canonical matrix: ladder, status, procedures; the validation process behind every support claim is in [https://git.vgpu.io/open-iov.git/tree/docs/06-portability/03-device-validation-and-porting-sequence.md <code>../docs/06-portability/03-device-validation-and-porting-sequence.md</code>].
	* [https://git.vgpu.io/open-iov/~~blob/master~~/docs/05-operations/01-performance-correctness-security.md <code>../docs/05-operations/01-performance-correctness-security.md</code>] — the five-rung evaluation ladder and evidence rules.		* [https://git.vgpu.io/open-iov.git/tree/docs/05-operations/01-performance-correctness-security.md <code>../docs/05-operations/01-performance-correctness-security.md</code>] — the five-rung evaluation ladder and evidence rules.
	* [[Project Status\|<code>Project-Status.md</code>]] and [[System Overview\|<code>System-Overview.md</code>]] — current status and component map.		* [[Project Status\|<code>Project-Status.md</code>]] and [[System Overview\|<code>System-Overview.md</code>]] — current status and component map.
	* [[risc-v-gsp-rm-debugger\|<code>Riscv-GSP-RM-Debugger.md</code>]] — firmware-side portability analysis.		* [[risc-v-gsp-rm-debugger\|<code>Riscv-GSP-RM-Debugger.md</code>]] — firmware-side portability analysis.
	* [[HAAEEP and Collaboration\|<code>HAAEEP-and-Collaboration.md</code>]] — the edge use case and collaboration models.		* [[HAAEEP and Collaboration\|<code>HAAEEP-and-Collaboration.md</code>]] — the edge use case and collaboration models.