ConnectX-6 Dx – PSID Change and VF Trust Mode Enablement/Exposure Without Capability Loss

We are seeking assistance and guidance regarding PSID migration and VF Trust Mode enablement/exposure on ConnectX-6 Dx adapters operating in a VMware ESXi 7.0 U3 environment.

Deployment Overview:

  • NIC Model: NVIDIA ConnectX-6 Dx (OPN: MCX623106AC-CDA_Ax)
  • Firmware: 22.43.2566
  • Host OS: VMware ESXi 7.0 Update 3
  • Guest OS: Ubuntu 22.04 / 24.04 with SR-IOV passthrough enabled
  • Pre-Boot UEFI Utility: Used to configure SRIOV_EN and NUM_OF_VFS; TRUST_MODE not exposed

Objective:

Enable VF Trust Mode to allow advanced network operations (e.g., VLAN management and monitoring) on Virtual Functions passed through to guest VMs.

Current Obstacles:

  • TRUST_MODE is not visible in UEFI or configurable via mlxconfig.

  • Attempted PSID change from MT_0000000436 to MT_0000000438 using this command at the ESXi shell with host in maintenance mode and mst in recovery mode:

    flint -d <mt_device> -i .bin --allow_psid_change --no_fw_ctrl burn

    Resulted in the following error:
    Burning FS4 image failed: Changing PSID is unsupported under controlled FW.

  • The system was prepared per MFT guidelines: passthrough was disabled, the firmware was verified, tools were up to date, and firmware/PSID backups were taken prior to flashing.

Technical Constraints:

Any alternative firmware or PSID must retain all existing NIC capabilities, including:

  • Dual-port functionality
  • Crypto features
  • Secure Boot compatibility

The attempted PSID (MT_0000000438) was evaluated solely to expose VF Trust Mode but does not meet capability preservation requirements.

Information and assistance Sought:

We welcome input from those with experience in similar NIC configurations or firmware migrations:

  1. Is PSID migration supported on MCX623106AC-CDA_Ax under any specific firmware conditions?
  2. Are non-controlled firmware builds available that permit PSID modification for this OPN?
  3. Are there supported PSIDs that expose TRUST_MODE setting without disabling dual-port, crypto, or secure boot functionality – w/o defeating the necessary security requirements?
  4. If firmware-level TRUST_MODE exposure is not possible, are there known alternatives?

Any confirmed experience, documentation references, or workaround strategies would be ––appreciated.