SysadminNews

Nova: what TLV firmware and vGPU boot actually add

On this page
  1. Where the Linux 7.3 work fits
  2. How the firmware container is laid out
  3. A container is not a compatibility promise

Nova’s firmware work improves how the driver finds and starts GPU components. A successful firmware boot is still a different milestone from delivering a usable virtual GPU to an application.

Original NVFW layout exercise: magic header 4 bytes; one fictional block contains tag 4, length field 4, value 3 and padding 1, totaling 12 bytes. The length value is 3. Not an actual firmware dump.
Original NVFW layout exercise: magic header 4 bytes; one fictional block contains tag 4, length field 4, value 3 and padding 1, totaling 12 bytes. The length value is 3. Not an actual firmware dump. Chart : PeopleAreGeek. Data source.
View full-size image

Where the Linux 7.3 work fits

The DRM pull request for 7.3-rc1 lists GSP boot consolidation, boot with vGPU enabled and TLV firmware support. The current Nova architecture documentation separates nova-core, the hardware/firmware foundation, from second-level users such as nova-drm and a vGPU manager VFIO driver.

That architecture is not evidence that every layer is production-ready on every NVIDIA card. Boot, resource management, isolation, guest drivers and application behavior must work together. Do not interpret a boot-related entry in a kernel pull as a supported deployment recipe for arbitrary hardware.

How the firmware container is laid out

The TLV specification starts with NVFW magic, followed by blocks containing a four-byte ASCII tag, a four-byte little-endian length and a value padded to four-byte alignment. Duplicate tags are forbidden. The parser must handle missing or malformed fields; the existence of a length field does not make arbitrary unknown content safe.

Our diagram works through a fictional three-byte value: four bytes of tag plus four of length plus three of data plus one of padding make a 12-byte block. The initial NVFW header adds four bytes separately. The length describes three data bytes, not four padded bytes. This is an original layout exercise, not a dump of actual firmware.

A container is not a compatibility promise

Tagged metadata helps identify components, but the consumer still needs to understand each required field and check that lengths remain within the available file. A well-formed container can still carry firmware inappropriate for a given GPU.

For developers, distinguish a parsing failure from authentication, boot and later device-operation failures. Those stages need different evidence. For desktop users, this work is best read as driver infrastructure progress, not a reason on its own to replace a working graphics setup.

September 8: explain actual NVFW TLV layout and parser responsibilities; separate GSP boot groundwork from a complete production vGPU stack.