NvHv Changes#

EACCES Error Code Return Value#

Target Changes

Backward Compatible

Platform

OS

In release 7.2.3.0, EACCES is added to the return values of NvHvConfigIrqRouting() in nvtegrahv_irq_routing.h.

Previously, the API did not return EACCES. With this change, EACCES may be returned as an additional error code.

Yes

NSR

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.x to 7.x

Migration Rationale

EOK represents success, so the addition of EACCES as a new error return value has minimal impact on existing applications. However, applications that exhaustively handle all possible error return values from NvHvConfigIrqRouting() should be updated to account for the new EACCES error code.

Steps to Migrate

If the application checks for specific error codes returned by NvHvConfigIrqRouting(), add handling for the EACCES error code. For example:

int ret;
ret = NvHvConfigIrqRouting(...);
if (ret != EOK) {
    if (ret == EACCES) {
        /* Handle access denied error */
    }
    /* Handle other errors */
}

Removal of the Unscoped BUF_SIZE Macro from nvtegrahv.h#

Target Changes

Backward Compatible

Platform

OS

The top-level BUF_SIZE macro (defined as 20, “Max digits for vmid”) has been removed from nvtegrahv.h. It was an internal implementation detail backing an NvHv VM-id read buffer — an unscoped name in the global preprocessor namespace that was unintentionally exposed through the public header — and was never intended for direct use. The public header no longer leaks it.

No. Source changes are required.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Eliminate an unscoped public macro that polluted the global preprocessor namespace.

Steps to Migrate

  1. BUF_SIZE was an internal implementation detail, not part of the supported API surface, so no action is required for normal NvHv usage. Source changes are only needed for code that accidentally referenced this unintended public macro (for example, code that used it to size a local buffer). Because the macro previously shipped in the public nvtegrahv.h, such code will fail to build with 'BUF_SIZE' undeclared; replace the reference with a local literal or a project-scoped constant.

    // Before
    char vmid_str[BUF_SIZE];
    
    // After
    char vmid_str[20];  // or define a local SCOPED constant
    

DISPLAY_VM Macro Now Gated by NV_IS_SAFETY#

Target Changes

Backward Compatible

Platform

OS

In nvtegrahv.h, the DISPLAY_VM macro (the environment variable name "DISPLAY_VM" used to look up the display VM id) is now gated by #if (NV_IS_SAFETY == 0), so it is no longer visible in QNX-safety builds. It was an internal implementation detail backing NvHvGetDisplayVmId() — whose display-VM surface has been unavailable in QNX-safety builds since DRIVE OS 6.x — rather than a macro applications were expected to use directly. The macro definition itself is unchanged on non-safety builds.

No. Source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Restrict the display-VM environment-variable indirection to non-safety builds; safety builds do not have a display path.

Steps to Migrate

DISPLAY_VM was an internal implementation detail backing NvHvGetDisplayVmId(), not a macro applications were expected to use directly. The display-VM surface has been gated out of QNX-safety builds since DRIVE OS 6.x, so QNX-safety code should not depend on it at all.

Source changes are only required for code that accidentally relied on this unintended public macro. For QNX-safety builds, guard or remove any remaining DISPLAY_VM references rather than substituting a literal string. Compile-time signal of this break: 'DISPLAY_VM' undeclared (under NV_IS_SAFETY=1).

// QNX-safety build: the display-VM surface is unavailable.
// Guard or remove display-VM references; do not rely on the
// DISPLAY_VM macro.
#if (NV_IS_SAFETY == 0)
    const char *envname = DISPLAY_VM;
    // ... display-VM lookup (non-safety builds only) ...
#endif

NvHvYieldVcpu() Return-Code Reorganization (Linux/QNX Split)#

Target Changes

Backward Compatible

Platform

OS

The NvHvYieldVcpu() (in nvtegrahv_yield_vcpu.h) @return list has been reorganized and split into QNX and Linux variants:

  • ETIMEDOUT is now QNX-only (“Success - VCPU is yielded successfully and taken back to Guest VM by timeout”). It no longer appears on Linux.

  • Two distinct EINVAL classifications replace the previous single one: a Linux-flavored “Invalid timeout_us parameter (zero or exceeded maximum value)” and a QNX-flavored “Invalid timeout_us parameter (zero or exceeded maximum value) or general error at devctl call”.

  • A new EACCES return (“Client doesn’t have privilege to call this API”) has been added on QNX.

No. Source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

6.5.4.2 to 7.2.5.0

Migration Rationale

Reflect the actual implementation differences between the QNX and Linux yield drivers and surface the privilege-denial path consistent with the existing nvhv/yield_vcpu custom ability.

Steps to Migrate

Update code that classifies NvHvYieldVcpu() failures by errno to handle the new QNX-only EACCES return and to no longer expect ETIMEDOUT on Linux.

switch (NvHvYieldVcpu(vmid, 1000U)) {
case EOK:        /* yielded then resumed */ break;
case ETIMEDOUT:  /* QNX-only success */ break;
case EACCES:     /* QNX-only privilege denied */ break;
default: break;
}