Skip to content

UBUNTU: [Config] nvidia: disable KHO by default on arm64-nvidia - #591

Closed
SloptimistPrime wants to merge 417 commits into
NVIDIA:26.04_linux-nvidiafrom
SloptimistPrime:sloptimistprime/26.04-arm64-disable-kho-default
Closed

SloptimistPrime wants to merge 417 commits into
NVIDIA:26.04_linux-nvidiafrom
SloptimistPrime:sloptimistprime/26.04-arm64-disable-kho-default

Conversation

@SloptimistPrime

Copy link
Copy Markdown

This recreates #590 on the requested 26.04_linux-nvidia base.

Failure

On two GB10/DGX Spark systems, Linux 7.0.0-1019.19~24.04.2 deterministically fails long-term page pinning under high GPU-memory pressure. NVIDIA driver 595.84, ConnectX-7 firmware 28.45.4028, userspace, container, and test binary were held constant; both systems pass with Linux 6.17.13.

Kernel return tracing identifies the first failure in migrate_pages(), followed by -ENOMEM from __gup_longterm_locked() and pin_user_pages_fast(). It then propagates through ib_umem_get() and mlx5_ib_reg_user_mr() to ibv_reg_mr_iova2(). NCCL errors and rank loss occur later.

Default-enabled KHO reserves 4,761 scratch pageblocks, about 9.30 GiB, and releases them as MIGRATE_CMA. On these systems, /proc/meminfo reports CmaTotal=0 with approximately 9.7 GiB in CmaFree.

A/B result

With the same Linux 7 image and workload:

  • KHO enabled fails the first 4 KiB and 1 MiB registrations at 108 GiB of committed CUDA pressure.
  • Adding only kho=off produces zero CMA pageblocks, CmaTotal=0, CmaFree=0, recovers about 9.5 GiB, and passes all 4,096 retained 1 MiB registrations with exact cleanup on both systems.
  • Encoding CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=n, with no kho= or cma= command-line override, produces the same passing result.

The config candidate passed direct and switched built-in NCCL IB collectives at idle and under 108 GiB pressure, a sockets control, and both TP2 DeepSeek model smoke tests on both systems. Logs contain no transport fallback, registration error, NCCL failure, or rank loss.

Scope and 26.04 validation

KHO remains compiled and can be enabled explicitly with kho=on. Only the 4K arm64-nvidia flavour changes; arm64-nvidia-64k retains its inherited default.

Against 26.04_linux-nvidia at b2db142cd58ca28c86755332e27bb547efee6ce4, both the Ubuntu annotation export and Linux olddefconfig pass:

  • arm64-nvidia: CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT unset
  • arm64-nvidia-64k: CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y
  • both: CONFIG_KEXEC_HANDOVER=y

The two-node runtime validation used the Linux 7.0.14 candidate source; this PR's 26.04 branch validation is config-level.

A Spark-specific kho=off policy in the product bootloader package would be narrower than kernel-flavour policy. NVIDIA's current DGX OS documentation identifies dgxstation-grub as the workstation bootloader configuration package. I can move the policy there if that is the intended component.

Discussion: https://forums.developer.nvidia.com/t/dgx-spark-regression-kernel-7-0-0-1019-nvidia-causes-nccl-roce-ibv-reg-mr-iova2-enomem-6-17-0-1032-works/383023

nvmochs and others added 30 commits September 11, 2026 08:43
BugLink: https://bugs.launchpad.net/bugs/2119656

Ensure ACPI table reads are successful prior to using the value.

Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Kai-Heng Feng <kaihengf@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Acked-by: Koba Ko <kobak@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit b2947b0 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 9258355 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 2c5b472 noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit 3f72f24 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656

Some environments may provide a "nvidia,egm-retired-pages-data-base” but
fail to populate it with a base address, leaving it NULL. Mapping this
invalid value results in a synchronous exception when the region is first
touched. Detect a NULL value, generate a warning to draw attention to the
firmware bug, and return without mapping.

INFO:    th500_ras_intr_handler: External Abort reason=1 syndrome=0x92000410 flags=0x1
[   82.104493] Internal error: synchronous external abort: 0000000096000410 [NVIDIA#1] SMP
[   82.114898] Modules linked in: nvgrace_gpu_vfio_pci(E) nvgrace_egm(E)
[   82.257218] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G           OE      6.8.12+ NVIDIA#5
[   82.265135] Hardware name: NVIDIA GH200 P5042, BIOS 24103110 20241031
[   82.271720] Workqueue: events work_for_cpu_fn
[   82.276180] pstate: 03400009 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[   82.283298] pc : register_egm_node+0x2cc/0x440 [nvgrace_egm]
[   82.289087] lr : register_egm_node+0x2c4/0x440 [nvgrace_egm]
[   82.294872] sp : ffff8000802ebc30
[   82.298254] x29: ffff8000802ebc60 x28: 00000000000000ff x27: 0000000000000000
[   82.305550] x26: ffff000087a320c8 x25: ffff0000a5700000 x24: ffff000087a32000
[   82.312846] x23: ffffa77cd758e368 x22: 0000000000000000 x21: ffffa77cd758c640
[   82.320141] x20: ffffa77cd758e170 x19: ffff800081e7d000 x18: ffff800080293038
[   82.327437] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   82.334732] x14: 0000000000000000 x13: 65203a65646f6e5f x12: 0000000000000000
[   82.342027] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[   82.349322] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[   82.356618] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[   82.363913] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800081e7d000
[   82.371210] Call trace:
[   82.373705]  register_egm_node+0x2cc/0x440 [nvgrace_egm]
[   82.379135]  nvgrace_gpu_probe+0x2ac/0x528 [nvgrace_gpu_vfio_pci]
[   82.385366]  local_pci_probe+0x4c/0xe0
[   82.389198]  work_for_cpu_fn+0x28/0x58
[   82.393026]  process_one_work+0x168/0x3f0
[   82.397123]  worker_thread+0x360/0x480
[   82.400952]  kthread+0x11c/0x128
[   82.404248]  ret_from_fork+0x10/0x20
[   82.407906] Code: d2820001 940002b3 aa0003f3 b4fffac0 (f9400017)
[   82.414134] ---[ end trace 0000000000000000 ]---

Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Kai-Heng Feng <kaihengf@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Acked-by: Koba Ko <kobak@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 7ba2930 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 349fb1c https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 6e9c94a noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit c5992d5 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656

In an effort to simplify the programming model, use a symmetrical model
for the the EGM regsiration APIs. This avoids the caller needing to keep
a cookie or even have knowlege of if EGM is supported. Update the EGM
unregisration API to use the PCI device as its parameter.

Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit d8903ec https://github.com/nvmochs/NV-Kernels/tree/vegm_01232025)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 5839fc5 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit f6fb40e noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit 0e607bc noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…egions

BugLink: https://bugs.launchpad.net/bugs/2119656

GB200 systems could have multiple GPUs associated with
an EGM region. For proper EGM functionality the host
topology in terms of GPU affinity has to be replicated
in the VM. Hence the EGM region structure must track the
GPU devices belonging to the same socket.

On the device probe, the device pci_dev struct is added to a
linked list of the appropriate EGM region.

Similarly on device remove, the pci_dev struct for the GPU
is removed from the EGM region.

Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Ref: sj24: /home/nvidia/ankita/kernel_patches/0001_vfio_nvgrace-egm_track_GPUs_associated_with_the_EGM_regions.patch
(koba: Enhance error handling, Remove egm_node from unregister_egm_node
and move destroy_egm_chardev a little forward)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 0222c35 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 5ba1a1f noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit c167095 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656

To replicate the host EGM topology in the VM in terms of
the GPU affinity, the userspace need to be aware of which
GPUs belong to the same socket as the EGM region.

Expose the list of GPUs associated with an EGM region
through sysfs. The list can be queried from the location
/sys/devices/virtual/egm/egmX/gpu_devices.

Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Ref: sj24: /home/nvidia/ankita/kernel_patches/0002_vfio_nvgrace-egm_list_gpus_through_sysfs.patch
(koba: Enchance error handling for sysfs_create_group)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit fec2356 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 5dde2f0 noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit a5284ca noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656

To allocate the EGM, the userspace need to know it's size. Currently,
there is no easy way for the userspace to determine that.

Make nvgrace-egm expose the size through sysfs that can be queried
by the userspace from /sys/devices/virtual/egm/egmX/egm_size.

Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Ref: sj24: /home/nvidia/ankita/kernel_patches/0003_vfio_nvgrace-egm_expose_the_egm_size_through_sysfs.patch
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit dcdcef2 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 9940157 noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit e025c29 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…y_failure

BugLink: https://bugs.launchpad.net/bugs/2138892

EGM carveout memory is mapped directly into userspace (QEMU) and is not
added to the kernel. It is not managed by the kernel page allocator and
has no struct pages. The module can thus utilize the Linux memory manager's
memory_failure mechanism for regions with no struct pages. The Linux MM
code exposes register/unregister APIs allowing modules to register such
memory regions for memory_failure handling.

Register the EGM PFN range with the MM memory_failure infrastructure on
open, and unregister it on the last close. Provide a PFN-to-VMA offset
callback that validates the PFN is within the EGM region and the VMA,
then converts it to a file offset and records the poisoned offset in the
existing hashtable for reporting to userspace.

Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 3fde504 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656

Return the intended errno upon a copyout fault, remove unnecessary
checks following container_of pointer derivation, and use the correct
macro and types for overflow checking.

Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Kai-Heng Feng <kaihengf@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Acked-by: Koba Ko <kobak@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 429910b https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.8-next)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit bda63f3 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 942bf3b noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit 63dd059 noble:linux-nvidia-6.17)
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
… allocations

BugLink: https://bugs.launchpad.net/bugs/2119656

Add missing null pointer checks after vzalloc() calls in the NVIDIA
Grace GPU driver's EGM (External GPU Memory) handling code. This
prevents potential null pointer dereferences in the memory failure
handling and bad page fetching functions, providing proper error
handling for allocation failures.

Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L. Soto <csoto@nvidia.com>
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
(cherry picked from commit 63127e2 https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-adv-6.11-next)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit e5f0c8d noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(backported from commit 862ed5a noble:linux-nvidia-6.17)
[mochs: Addressed collission for a null pointer check that is no longer needed]
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2142160

When initializing EGM (Extended GPU Memory) regions, the current
implementation performs a single memset operation over the entire
memory region. For very large regions, this can result in long-running
uninterruptible operations that may cause system responsiveness issues
or trigger watchdog timeouts.

Split the memset operation into 1GB chunks.

Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 3554744 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656

Add CONFIG_NVGRACE_EGM with policy 'm' for arm64 architecture.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit ddf68d0 noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
(cherry picked from commit 9ef26d9 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2028576

The bug indicates NVIDIA wanted to enable the performance governor by
default on all arches for the NVIDIA kernels. However, this was
mistakenly only configured for arm64 systems. Fix this by also using the
performance CPU frequency governor as the default on amd64 systems.

Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
(cherry picked from commit a530411)

(cherry picked from commit a530411 noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit 93d3ca3 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2123861

In nvidia_ffa_create_notifications(), it invokes
nvidia_ffa_fill_notification_map(), which fills the virtual notification
IDs array supported by the current FFA device. This function updates
notification_count after traversing the notification array in the _DSD
method. For FFA devices without an entry in the _DSD method,
notification_count is assumed to be zero initialized.

However, nvidia_ffa_ec_service_probe() uses kmalloc() instead of kzalloc(),
so notification_count may contain random values. This causes FFA device
probe failures.

This patch fixes this by using kzalloc() to zero initialize the
nvidia_ec_ffa_device structure.

Fixes: ae87187 ("NVIDIA: SAUCE: Add support for notifications from secure EC services")
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 518a89b noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit bf0587b noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…PORTLI value

BugLink: https://bugs.launchpad.net/bugs/2125126

For DIGITS GB10, USB SuperSpeed Plus Gen2x1 device enumeration speed is
being shown as Gen2x2 in the dmesg log.

  usb 4-1: new SuperSpeed Plus Gen 2x2 USB device number 2 using xhci-hcd

The USB3 link lanes count is recorded in the read-only
TLC and RLC fields of the PORTLI register. In MT89xx SoCs (used by GB10),
the lane count can be wrongly set to 2 instead of 1 for USB Gen2x1
devices due to HW Bug. As per Table 7-13 in USB xHCI revision 1.2
specification, the value 0x5 is for SuperSpeedPlus Gen2x1.

This patch adds a SW WAR to read the port speed in PORTSC register.
If port speed value is 0x5, then the lane count can be updated to 1.

Signed-off-by: Us Chien <us.chien@mediatek.com>
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Kai-Heng Feng <kaihengf@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit b5b3a58 noble:linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit c654995 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2112600

iommu/io-pgtable-arm: Support contiguous bit in translation tables

The contiguous bit in translation table entries can be used as a hint to
SMMU that a group of adjacent translation table entries have consistent
attributes and point to a contiguous and properly aligned output address
range. This enables SMMU to predict the properties of the remaining
translation table entries in the same group without accessing them. It
also allows an SMMU implementation to make more efficient use of its TLB
by using a single TLB entry to cover all translation table entries in
the same group.

In the case of 4KB granule size, there are 16 translation table entries
in one group.

This change sets the contiguous bit for such groups of entries that are
completely covered by a single call to map_pages. As it stands, the code
wouldn't set the contiguous bit if a group of adjacent descriptors is
completed by separate calls to map_pages.

Signed-off-by: Daniel Mentz <danielmentz@google.com>
Link: https://lore.kernel.org/linux-iommu/20250430231924.1481493-1-danielmentz@google.com/
[aritger: For the backport: updated the __arm_lpae_init_pte() callsite in
arm_lpae_split_blk_unmap() (arm_lpae_split_blk_unmap() is no longer
present at top of tree where the original commit was written).]
Signed-off-by: Andy Ritger <aritger@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>
(backported from commit 990fa55 linux-nvidia-6.11)
[kobak: arm_lpae_split_blk_unmap is removed since https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33729a5fc0caf7a97d20507acbeee6b012e7e519
iommu/io-pgtable-arm: Remove split on unmap behavior so modify as per functions]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Signed-off-by: Ian May <ianm@nvidia.com>

(cherry picked from commit c601e60 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2129209

Add CSA (Channel Switch Announcement) related implementation
in collaboration with mac80211 to deal with dynamic channel
switching.

Signed-off-by: Leon Yen <leon.yen@mediatek.com>
Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>

Conflicts:
- drivers/net/wireless/mediatek/mt76/mt7925/main.c
  Code is different in mt7925_add_interface()

- drivers/net/wireless/mediatek/mt76/mt792x_core.c
  Code organization is different

Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
[Backported from https://patchwork.kernel.org/project/linux-wireless/patch/20250926053447.4036650-1-mingyen.hsieh@mediatek.com/]
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Ian May <ianm@nvidia.com>

(cherry picked from commit 060dc92 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
[maskedarray: fixed context changes due to removal of rfkill_poll function]
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
…ype to DMA

BugLink: https://bugs.launchpad.net/bugs/2129776

Force DGX Spark systems to use DMA translation as current drivers
require this.

Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Ian May <ianm@nvidia.com>

(cherry picked from commit 54575cf noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…LT_PASSTHROUGH

BugLink: https://bugs.launchpad.net/bugs/2129776

Default to CONFIG_IOMMU_DEFAULT_PASSTHROUGH on NVIDIA CPU on kernel
above 6.11 as suggested by perf team. x86 always defaults to
CONFIG_IOMMU_DEFAULT_DMA_LAZY so remove redundant amd64 setting.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Ian May <ianm@nvidia.com>

(backported from commit e74a7d8 noble:linux-nvidia-6.17)
[mochs: Addressed minor context collission]
Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2130445

The call to cat registers2 will acquire rtnl_lock and dump all
mapped mmio. Due to acquire rtnl_lock too long, it will cause a
kernel panic "not syncing: SBSA Generic Watchdog timeout". Fix this
issue by acquiring rtnl_lock every 16 byte when dump all mapped
mmio.

Signed-off-by: ChunHao Lin <hau@realtek.com>
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Ian May <ian.may@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 9737b84 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2130445

Use following command to do the test.

cat /proc/net/r8127/<devname>/test/cdt

Signed-off-by: ChunHao Lin <hau@realtek.com>
Signed-off-by: Abhishek Sahu <abhsahu@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Ian May <ian.may@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit aaf12ca noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
… existing iommu quirk

BugLink: https://bugs.launchpad.net/bugs/2132033

Add two more device IDs for the existing Spark iommu quirk.

Link: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-6.14/+bug/2132033

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off--by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit ba93154 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2134991

Remove registers2 proc entry as it is causing system crash on running
opensource LTP test suite.

Change-Id: I47846bca0401d4403fba026d4a348eef3d454f80
Signed-off-by: ChunHao Lin <hau@realtek.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 4ff6f9f noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
… DGX Spark

BugLink: https://bugs.launchpad.net/bugs/2138269

This driver manages PCIe link for NVIDIA ConnectX-7 (CX7) hot-plug/unplug
on DGX Spark systems with GB10 SoC. It disables the PCIe link
on cable removal and enables it on cable insertion.

Upstream-friendly improvements over 6.14 driver:
- Separated from MTK pinctrl driver into NVIDIA platform driver
- Configuration via ACPI (_CRS and _DSD), no hardcoded values
- Device-managed resources (devm_*) for automatic cleanup
- Thread-safe state management with locking
- Enhanced error handling and logging
- Uses standard Linux kernel APIs

The driver exposes a sysfs interface to emulate cable plug in/out:
  echo 1 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/debug_state  # plug in
  echo 0 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/debug_state  # plug out

It also provides a runtime enable/disable switch via sysfs:
  echo 1 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/hotplug_enabled  # Enable
  echo 0 > /sys/devices/platform/MTKP0001:00/pcie_hotplug/hotplug_enabled  # Disable

This allows enabling/disabling hotplug functionality. Hotplug is disabled by default
and must be explicitly enabled via userspace.

It also implements uevent notifications for coordination with userspace:

* cable plug-in:
    Report plug-in uevent (driver)
    Enable PCIe link (driver)
    Rescan CX7 devices (application)

* cable removal:
    Report removal uevent (driver)
    Remove CX7 devices (application)
    Disable PCIe link (driver)

Signed-off-by: Vaibhav Vyas <vavyas@nvidia.com>
Signed-off-by: Scott Fudally <sfudally@nvidia.com>
Signed-off-by: Surabhi Chythanya Kumar <schythanyaku@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 4894eb0 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2059814

Signed-off-by: Brad Figg <bfigg@nvidia.com>
Acked-by: Brad Figg <bfigg@nvidia.com>
Acked-by: Ian May <ian.may@canonical.com>
Signed-off-by: Ian May <ian.may@canonical.com>
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
(cherry picked from commit a64b597
linux-nvidia-6.14)
Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>

(cherry picked from commit 67713ae noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2137588

Add KERN_INFO log level for GPL_CLAIM to downgrade warning messages

Signed-off-by: ChunHao Lin <hau@realtek.com>
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Signed-off-by: Muteeb Akram <mdoctor@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit 3c12da3 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2138132

Fix this warning about missing prototype:

	../drivers/vfio/vfio_main.c:1369:21: warning: no previous prototype for ‘vfio_device_from_file’ [-Wmissing-prototypes]
	 1369 | struct vfio_device *vfio_device_from_file(struct file *file)
	      |                     ^~~~~~~~~~~~~~~~~~~~~

Add the declaration in the header since it's no different than e.g. vfio_file_is_valid() that is there
and remove the extern in the .c.

Signed-off-by: Lucas De Marchi <ldemarchi@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Acked-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(backported from commit 006a865 noble:linux-nvidia-6.17)
[jacobmartin: upstream did not have the extern in nvgrace-gpu/main.c]
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2093957

Signed-off-by: Jeremy Szu <jszu@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Abdur Rahman <abdur.rahman@canonical.com>
Acked-by: Noah Wager <noah.wager@canonical.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit a15be6b noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2138892

Remove this declaration which is now used within the file
after merging upstream "vfio/nvgrace-gpu: register device memory for
poison handling".

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>

(cherry picked from commit e78ec36 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…xplicitly

The virtual nvidia-kernel-source and nvidia-dkms-kernel dependencies
would sometimes pull the 470 driver, which is incompatible with the
nvidia-fs build.

Stick to the latest LTS. This could be made to use the virtual packages
again once the 470 driver transitionals are released.

Ignore: yes
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

(cherry picked from commit 73a27bb noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2093957

The patch "UBUNTU: [Packaging] Enable coresight in Perf if arm64"
enables perf to be built with CORESIGHT=1 on arm64. This requires
libopencsd.

Signed-off-by: Jacob Martin <jacob.martin@canonical.com>

(cherry picked from commit f95fa30 noble:linux-nvidia-6.17)
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
u1f35c and others added 22 commits September 11, 2026 08:43
…sync

BugLink: https://bugs.launchpad.net/bugs/2166208

The Linux IMA (Integrity Measurement Architecture) subsystem used for
secure boot, file integrity, or remote attestation cannot be a loadable
module for few reasons listed below:

 o Boot-Time Integrity: IMA’s main role is to measure and appraise files
   before they are used. This includes measuring critical system files
   during early boot (e.g., init, init scripts, login binaries). If IMA
   were a module, it would be loaded too late to cover those.

 o TPM Dependency: IMA integrates tightly with the TPM to record
   measurements into PCRs. The TPM must be initialized early (ideally
   before init_ima()), which aligns with IMA being built-in.

 o Security Model: IMA is part of a Trusted Computing Base (TCB). Making
   it a module would weaken the security model, as a potentially
   compromised system could delay or tamper with its initialization.

IMA must be built-in to ensure it starts measuring from the earliest
possible point in boot which inturn implies TPM must be initialised and
ready to use before IMA.

Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM
devices) are not reliably available during the initcall_late stage,
resulting in a log error:

  ima: No TPM chip found, activating TPM-bypass!

To address this issue, IMA_INIT_LATE_SYNC is introduced.
However, a remote attestation service cannot determine when IMA has been
initialized because the boot_aggregate measurement name remains unchanged,
even though IMA is initialized later at late_initcall_sync when
IMA_INIT_LATE_SYNC is enabled.

Therefore, use a distinct boot_aggregate name when IMA_INIT_LATE_SYNC
is enabled, allowing the remote attestation service to identify
when IMA has been initialized.

Signed-off-by: Jonathan McDowell <noodles@meta.com>
[yeoreum.yun@arm.com: modified to align with the IMA_INIT_LATE_SYNC change]
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
(cherry picked from commit c0fc127)
Signed-off-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2166208

commit 746d9e9 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in")
probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.

However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
initialises IMA at the late_initcall_sync level, so this change is no
longer required.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Link: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/commit/?h=for-next/ffa/updates&id=cc7e8f21b9f0c229d68cf19a837cba82b5ac2d87 [0]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/commit/?h=for-next/ffa/updates&id=e659fc8e537c7a21d5d693d6f30d8852f2fa8d91 [1]
Link: https://lore.kernel.org/r/20260605144325.434436-5-yeoreum.yun@arm.com
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
(cherry picked from commit 677042a)
Signed-off-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2166208

The platform core invokes a driver's shutdown callback, rather than its
remove callback, while preparing devices for a normal kexec. Without a
shutdown callback, the FF-A driver leaves notifications, partition devices,
and the RX/TX mapping active before the replacement kernel is booted.

Use ffa_remove() for shutdown so the existing cleanup runs before a normal
kexec and other orderly system shutdowns.

Reported-by: Nat Gurumoorthy <natg@google.com>
Closes: https://lore.kernel.org/all/20260729162731.1383875-1-natg@google.com/
Reported-by: Carol L Soto <csoto@nvidia.com>
Closes: https://lore.kernel.org/all/20260818224404.3694580-1-csoto@nvidia.com
Reported-by: Maxi Saparov <masaparov@coreweave.com>
Closes: https://lore.kernel.org/all/20260826222337.73480-1-maxi.saparov@gmail.com
Link: https://patch.msgid.link/20260901131112.3437516-1-sudeep.holla@kernel.org
Tested-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
(cherry picked from commit 3bb3e80 linux-next)
Signed-off-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2166208

Enable IMA_INIT_LATE_SYNC for arm64 so IMA runs
after deferred TPM CRB-over-FF-A probing.

Signed-off-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
…-page kernels

BugLink: https://bugs.launchpad.net/bugs/2166792

OP-TEE FF-A memory objects use 4 KiB pages, while the kernel page
size may be larger. Consequently, tee_shm->offset can be greater than
or equal to FFA_PAGE_SIZE, but OP-TEE rejects such a value in
internal_offs.

Do not encode the excess page offset in offs_low/offs_high. Those
fields describe the logical memref offset and are copied back into
tee_param->shm_offs on return. Folding the page offset into them breaks
parameter round trips when a memref is reused. They are also ignored by
the OPTEE_RPC_CMD_SHM_ALLOC response path, which uses only global_id and
internal_offs to construct the shared-memory mobj.

Instead, start the FF-A descriptor at the 4 KiB page containing the
shared buffer, the same approach as optee_fill_pages_list() in the SMC
ABI. Store the remaining in-page offset in internal_offs and preserve
shm_offs in offs_low/offs_high. This keeps internal_offs within the
FF-A page size, maps RPC allocations at the correct address, and
preserves normal memref offsets across repeated invocations.

Tested on ARMv8-A with 64 KiB PAGE_SIZE. OP-TEE OS ran as a secure
partition under Hafnium (SPMC) over FF-A. Verified registered shared
memory with tee_shm->offset >= 4 KiB, memref reuse on the same
TEEC_Operation, and RPC OPTEE_RPC_CMD_SHM_ALLOC (xtest regression
6007-6009). optee_hello_world, optee_aes, and xtest regression 1005,
1007, 1008, 4001-4003 and 6001-6003 also passed.

Fixes: 4615e5a ("optee: add FF-A support")
(backported from https://lore.kernel.org/r/20260904134732.1072541-1-mahantesh@nvidia.com)
Signed-off-by: Mahantesh Salimath <mahantesh@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2166545

DisplayPort supports EDID up to 256 bytes (blocks 0 and 1). Update the
block check to allow these two blocks. For any block beyond that
(i.e. the monitor's EDID is larger than the 256 bytes ASPEED DP can
hold), report it as an all-zero block instead of a read failure.

Also remove the manual checksum/extension-count patch of block 0's
last four bytes. That code was already dead, so the condition can never
be true.

Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260819-upstream_ast_dp_edid-v3-1-15d36c28afe2@aspeedtech.com
(cherry picked from commit b35be235d92b2826e1111bff4c85e080ffd8ca28 drm-misc-next)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
Ignore: yes
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2167007
Properties: no-test-build
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…or amd64

This option was intended to be enabled only for arm64. Annotations
needed updating to specify a value for amd64.

Ignore: yes
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2166188

In aggregation mode with two identical amplifiers,
a stress test that repeatedly triggers card unbind/rebind
can hit a NULL pointer dereference during the exit path.
ctx->amp_dev1 / ctx->amp_dev2 are single shared resources,
so the release must be safe against being called more than once.
Clear each pointer after put_device() so a second invocation
becomes a no-op, this could address NULL pointer dereference issue.

Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://patch.msgid.link/20260818023018.2564212-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 046173b)
Signed-off-by: Kaushal Rajeev Butala <kbutala@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2166188

asoc_sdw_rt711_exit() drops the reference held in ctx->headset_codec_dev,
but leaves the pointer populated. If the card cleanup path reaches the exit
hook more than once after a failed or deferred probe, a later invocation
can reuse the stale pointer and call put_device() again.

Clear the pointer after put_device() so repeated cleanup becomes a no-op.
This avoids refcount underflow and possible oopses when later probe,
driver bind, or suspend paths walk the SoundWire bus after the device
reference was released.

This is similar to commit 046173b ("ASoC: sdw_utils: fix double
put_device() on aggregated amps").

Signed-off-by: David Cemin <dcemin@nvidia.com>
Signed-off-by: Kaushal Rajeev Butala <kbutala@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

Along with renaming the .move_notify() callback, rename the corresponding
dma-buf core function. This makes the expected behavior clear to exporters
calling this function.

Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260124-dmabuf-revoke-v5-2-f98fca917e96@nvidia.com
Signed-off-by: Christian König <christian.koenig@amd.com>
(cherry picked from commit 9530822)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

/tmp/next/build/drivers/infiniband/core/ib_core_uverbs.c: In function 'rdma_user_mmap_entry_remove':
/tmp/next/build/drivers/infiniband/core/ib_core_uverbs.c:249:17: error: implicit declaration of function 'dma_buf_move_notify' [-Wimplicit-function-declaration]
  249 |                 dma_buf_move_notify(uverbs_dmabuf->dmabuf);
      |                 ^~~~~~~~~~~~~~~~~~~

Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/aZyhDuaF5vi05KBY@sirena.org.uk
(cherry picked from commit 61c0f69)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

dma-buf invalidation is handled asynchronously by the hardware, so VFIO
must wait until all affected objects have been fully invalidated.

In addition, the dma-buf exporter is expecting that all importers unmap any
buffers they previously mapped.

Fixes: 5d74781 ("vfio/pci: Add dma-buf export support for MMIO regions")
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20260131-dmabuf-revoke-v7-4-463d956bd527@nvidia.com
(cherry picked from commit 1a8a522)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

Extend the checks in pcim_p2pdma_init() and pcim_p2pdma_provider() to
exclude functions that have pdev->non_mappable_bars set.

Consumers such as VFIO were previously able to map these for access by the
CPU or P2P.  Update the comment on non_mappable_bars to show it refers to
any access, not just userspace CPU access.

Fixes: 372d6d1 ("PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation")
Suggested-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Matt Evans <mattev@meta.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Alex Williamson <alex@shazbot.org>
Link: https://patch.msgid.link/20260423173051.1999679-1-mattev@meta.com
(backported from commit 951ebc1)
[kelseys: no changes to patch, resolved context conflict]
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

Sashiko points out this has gotten out of order, the mutex could still be
in use through the dmabuf invalidation callbacks. Don't destroy any of the
pages content until the dmabuf is fully detached.

Fixes: 71db84a ("iommufd: Add DMABUF to iopt_pages")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(cherry picked from commit f2d70db)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

IOMMU_IOAS_MAP_FILE is documented as mapping a memfd, but the
implementation first tries to resolve the fd as a dma-buf and has a
special path for supported dma-buf exporters. In particular, VFIO PCI
dma-bufs exported through VFIO_DEVICE_FEATURE_DMA_BUF can be mapped when
they describe a single DMA range.

Update the UAPI comment so userspace understands that certain kinds of
dma-buf are supported in addition to memfd.

Fixes: 44ebaa1 ("iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE")
Link: https://patch.msgid.link/r/20260610-tmp-v1-1-b8ccbf557391@fb.com
Signed-off-by: Alex Mastro <amastro@fb.com>
Assisted-by: Codex:gpt-5.5-high
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(cherry picked from commit 298ab7e)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

vfio_pci_dma_buf_move(revoked=true) and vfio_pci_dma_buf_cleanup()
ran the same drain sequence: set priv->revoked, invalidate mappings,
wait for fences, drop the registered kref, wait for completion.
When the VFIO device fd was closed after PCI_COMMAND_MEMORY had been
cleared, both ran in turn -- the second kref_put underflowed and the
subsequent wait_for_completion() blocked on a completion that the
first run had already consumed:

  refcount_t: underflow; use-after-free.
  WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x59/0x90
  Call Trace:
   vfio_pci_dma_buf_cleanup+0x163/0x168 [vfio_pci_core]
   vfio_pci_core_close_device+0x67/0xe0 [vfio_pci_core]
   vfio_df_close+0x4c/0x80 [vfio]
   vfio_df_group_close+0x36/0x80 [vfio]
   vfio_device_fops_release+0x21/0x40 [vfio]
   __fput+0xe6/0x2b0
   __x64_sys_close+0x3d/0x80

Collapse the duplication: vfio_pci_dma_buf_cleanup() now delegates
the drain to vfio_pci_dma_buf_move(true), which is idempotent for
already-revoked dma-bufs.  cleanup retains only list removal and
the device registration drop; the dma_resv_lock that bracketed
those is dropped along with the in-line drain that required it,
memory_lock continues to protect them.

Re-arm the kref and the completion at the end of move()'s revoke
branch so post-revoke state matches post-creation (kref == 1,
completion ready).  This keeps cleanup's call into move() a no-op
when revoke already ran, and replaces the explicit kref_init() that
the un-revoke branch used to perform for the un-revoke -> remap
path.

Fixes: 1a8a522 ("vfio: Wait for dma-buf invalidation to complete")
Reported-by: Joonas Kylmälä <joonas.kylmala@netum.fi>
Closes: https://lore.kernel.org/all/GVXPR02MB12019AA6014F27EF5D773E89BFB372@GVXPR02MB12019.eurprd02.prod.outlook.com/
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Alex Williamson <alex.williamson@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/20260507143548.1018405-1-alex.williamson@nvidia.com
Signed-off-by: Alex Williamson <alex@shazbot.org>
(cherry picked from commit c64a647)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

When dma_buf_export() succeeds but dma_buf_fd() fails (e.g. -EMFILE from
fd exhaustion), the dmabuf is leaked with no dma_buf_put() called.

Reproducer: exhaust fd table near RLIMIT_NOFILE, then repeatedly call
IOMMU_TEST_OP_DMABUF_GET — htop shows unbounded memory growth.

Fix by calling dma_buf_put(dmabuf) on error and returning directly.

Fixes: d2041f1 ("iommufd/selftest: Add some tests for the dmabuf flow")
Link: https://patch.msgid.link/r/20260707030635.221577-1-seven.yi.lee@gmail.com
Signed-off-by: yeeli <seven.yi.lee@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(cherry picked from commit dba4254)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
BugLink: https://bugs.launchpad.net/bugs/2167041

DMABUF pages are not supported for iommufd access pinning.
iommufd_access_pin_pages() returns struct page pointers for
in-kernel CPU access, but DMABUF-backed iopt_pages do not carry
a userspace address that can be passed to the GUP path.

iopt_pages_rw_access() already rejects IOPT_ADDRESS_DMABUF before doing
CPU access. Apply the same rejection to iopt_area_add_access() before it
takes pages->mutex and calls iopt_pages_fill_xarray().
Otherwise a DMABUF-backed iopt_pages can reach the hole-fill path, where
pfn_reader_user_pin() interprets the union as uptr and
calls pin_user_pages_fast()/pin_user_pages_remote().

This fix also avoids the lockdep warning reported from that path, where
pages_dmabuf_mutex_key is held while gup_fast_fallback() may acquire
mmap_lock.

Link: https://patch.msgid.link/r/CD68F549BF3761B7+20260709050800.520607-1-peiyang_he@smail.nju.edu.cn
Reported-by: Peiyang He <peiyang_he@smail.nju.edu.cn>
Closes: https://lore.kernel.org/all/E8540D7D05768C91+8b2ef227-3368-494e-909d-7b28e1489dfb@smail.nju.edu.cn/
Fixes: 71db84a ("iommufd: Add DMABUF to iopt_pages")
Cc: stable@vger.kernel.org
Tested-by: Peiyang He <peiyang_he@smail.nju.edu.cn>
Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(cherry picked from commit 5f3fc0a)
Signed-off-by: Kelsey Steele <kelseys@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
Kexec handover reserves scratch memory at twice the kernel-reserved-memory size and exposes it to the buddy allocator as MIGRATE_CMA. On GB10 this creates about 9.3 GiB of CMA pageblocks even though CmaTotal is zero. Under GPU memory pressure, FOLL_LONGTERM migration from those pageblocks fails and mlx5 memory registration returns ENOMEM.

Keep KHO available through the explicit kho=on command line, but do not enable it by default for the 4K arm64-nvidia flavour.

Link: https://forums.developer.nvidia.com/t/dgx-spark-regression-kernel-7-0-0-1019-nvidia-causes-nccl-roce-ibv-reg-mr-iova2-enomem-6-17-0-1032-works/383023
Assisted-by: Codex:gpt-6
Signed-off-by: Sloptimist Prime <sloptimistprime@sudomail.com>
@nirmoy

nirmoy commented Sep 14, 2026 •

Copy link
Copy Markdown
Collaborator

BaseOS Kernel Review

Tip

✅ Review passed

No issues found across the reviewed commits.

Findings: none

🔍 Review artifacts

📦 Kernel deb builds — 🟡 1/2 passed

Note

Build reports and debs are retained for 10 days after the PR closes.

Review metadata
  • Reviewed head: e5eccc02c333
  • Overall status: build partially successful
  • Architectures: 1/2 successful

This comment is maintained by BaseOS Reviewer and updated when the GitHub watcher publishes a newer review.

@github-actions

Copy link
Copy Markdown
Contributor

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details
Checking 1 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ e5eccc02c333 │ [UBUNTU] [Config] nvidia: disable KHO by default on arm64-nvidia │ N/A        │ N/A     │ sloptimi                  │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

PR metadata:
W: PR title missing [<branch>] prefix: "UBUNTU: [Config] nvidia: disable KHO by default on arm64-nvidia"
E: PR targets 26.04_linux-nvidia but body has no https://bugs.launchpad.net/... link

@SloptimistPrime

Copy link
Copy Markdown
Author

Follow-up validation after reports that kho=off may not help:

  • 595.84: KHO-default-off passed the 108 GiB/4,096-MR stress test, direct and switched NCCL, Vision TP2, and NVFP4 TP2 on both GB10 nodes.
  • 580.173.02: /proc/cmdline confirmed kho=off; CmaTotal=0, CmaFree=0, and no large CMA pageblock population. The MR stress test passed with passthrough and translated IOMMU. Vision TP2 passed twice on one boot over built-in NCCL IB with exact cleanup.
  • No ibv_reg_mr_iova2, ENOMEM, NV_ERR_NO_MEMORY, socket fallback, or rank loss occurred.

Scope: Linux 7.0.14 (ae07646) on NixOS with Secure Boot disabled. We have not run a DGX OS or Secure-Boot-on A/B. This confirms kho=off for the traced long-term GUP/RDMA failure, not every NVRM OOM or hang.

For a conflicting DGX OS result, the useful evidence is /proc/cmdline, CmaTotal/CmaFree, CMA pageblock counts, and the first error before shutdown noise.

@jamieNguyenNVIDIA

Copy link
Copy Markdown
Collaborator

Closing in favor of Matt's version of this change, which has been applied to Canonical resolute:

  • 26.04_linux-nvidia: #623, applied to main-next as 6cd2efe6ac6b UBUNTU: [Config] nvidia: default KHO off on arm64
  • 26.04_linux-nvidia-bos: #624, applied to nvidia-bos-next as a13abb6e7bba UBUNTU: [Config] nvidia-bos: default KHO off on arm64

Matt's version sets CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=n for all NVIDIA arm64 flavours (4K and 64K), not only arm64-nvidia. KHO stays built in and can still be enabled with kho=on.

Thanks for the detailed report and the kho=off A/B data behind this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

help wanted Extra attention is needed

Projects

None yet

Development

Successfully merging this pull request may close these issues.