Backport arch_topology stub fix to prevent build failure on ARM without CONFIG_GENERIC_ARCH_TOPOLOGY #282
+71,630
−672
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BugLink: https://bugs.launchpad.net/bugs/2119656 Fix minor syntax errors from sparse. 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 bbb64e6 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 fe78194 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 b192960 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@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>
BugLink: https://bugs.launchpad.net/bugs/2119656 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 afa8f63 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 d110330 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 a6c0508 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
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>
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 [#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+ #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>
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>
…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>
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>
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>
… 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>
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>
BugLink: https://bugs.launchpad.net/bugs/2119656 On platforms without the mig HW bug (e.g. Grace-Blackwell) there is not a requirement to create the resmem region. Accordingly, this region is not configured on these platforms, which leads to the following print when the device is closed: resource: Trying to free nonexistent resource <0x0000000000000000-0x000000000000ffff> Avoid calling unregister_pfn_address_space for resmem when the region is not being used. Fixes: 2d21b7b ("vfio/nvgrace-gpu: register device memory for poison handling") Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Carol L. Soto <csoto@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Matthew R. Ochs <mochs@nvidia.com> (cherry picked from commit bd0187d 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 87b2a68 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2119656 Commit 222675c ("irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by irqchips that need it") changed the behavior of CONFIG_IRQ_MSI_IOMMU to a dynamic selection, so it might not always be needed by amd64 builds. Signed-off-by: Matthew R. Ochs <mochs@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 c7c7b21 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
…DEFAULT_DMA_LAZY BugLink: https://bugs.launchpad.net/bugs/2119661 Nvidia CPU SMMU supports passthrough and lazy IOMMU mode so set lazy mode as default for better performance. Signed-off-by: Nirmoy Das <nirmoyd@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 6318c8c noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
…on amd64 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>
BugLink: https://bugs.launchpad.net/bugs/2121451 pci_acpi_preserve_config() leaks memory by returning early without freeing the ACPI object on success. Fix that by always freeing the obj, which is not needed by the caller. Fixes: 9d7d5db ("PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge()") Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250825214642.142135-1-nirmoyd@nvidia.com (cherry picked from commit dab2c5f9399591a50f9e9746fca6bb47f6ac04ae pci/misc) Signed-off-by: Nirmoy Das <nirmoyd@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 a1e5234 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2121544 GB300 is NVIDIA's Grace Blackwell Ultra Superchips with B300 GPU. Add the B300 SKU device-id to nvgrace_gpu_vfio_pci_table. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Carol L Soto <csoto@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@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 47c8566 noble:linux-nvidia-6.14) Signed-off-by: Abdur Rahman <abdur.rahman@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>
…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>
Ignore: yes Signed-off-by: Abdur Rahman <abdur.rahman@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2127212 Properties: no-test-build Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
As of 6.17 this flag is unused, so drop references to it to satisfy the cranky close linter. Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…backport 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/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>
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>
…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>
…DEFAULT_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>
…tmap controls BugLink: https://bugs.launchpad.net/bugs/2122432 MPAM has cache capacity controls that effectively take a percentage. Resctrl supports percentages, but the collection of files that are exposed to describe this control belong to the MB resource. To find the minimum granularity of the percentage cache capacity controls, user-space is expected to rad the banwdidth_gran file, and know this has nothing to do with bandwidth. The only problem here is the name of the file. Add duplicates of these properties with percentage and bitmap in the name. These will be exposed based on the schema format. The existing files must remain tied to the specific resources so that they remain visible to user-space. Using the same helpers ensures the values will always be the same regardless of the file used. These files are not exposed until the new RFTYPE schema flags are set on a resource 'fflags'. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 673bcb00d2371a2876e164da55d642fdf7657b8d https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…n schema format BugLink: https://bugs.launchpad.net/bugs/2122432 MPAM has cache capacity controls that effectively take a percentage. Resctrl supports percentages, but the collection of files that are exposed to describe this control belong to the MB resource. New files have been added that are selected based on the schema format. Apply the flags to enable these files based on the schema format. Add a new fflags_from_schema() that is used for controls. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit a837ccc258380d6aeef86df709cc0484b60a4acf https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 If more schemas are added to resctrl, user-space needs to know how to configure them. To allow user-space to configure schema it doesn't know about, it would be helpful to tell user-space the format, e.g. percentage. Add a file under info that describes the schema format. Percentages and 'mbps' are implicitly decimal, bitmaps are expected to be in hex. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit b457019d995b2849e683aef0fd89066e64c679a4 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 MPAM can have both cache portion and cache capacity controls on any cache that supports MPAM. Cache portion bitmaps can be exposed via resctrl if they are implemented on L2 or L3. The cache capacity controls can not be used to isolate portions, which is in implicit in the L2 or L3 bitmap provided by user-space. These controls need to be configured with something more like a percentage. Add the resource enum entries for these two resources. No additional resctrl code is needed because the architecture code will specify this resource takes a 'percentage', re-using the support previously used only for the MB resource. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit b601bbf375b016c417db4ec0e8bd6ae58b9057aa https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…m cmax BugLink: https://bugs.launchpad.net/bugs/2122432 MPAM's maximum cache-capacity controls take a fixed point fraction format. Instead of dumping this on user-space, convert it to a percentage. User-space using resctrl already knows how to handle percentages. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 183d4c43260089e6b51518e50427d0f04a6af875 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 The cpu hotplug lock has a helper lockdep_assert_cpus_held() that makes it easy to annotate functions that must be called with the cpu hotplug lock held. Do the same for memory. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit f40d4b8451b3d9e197166ff33104bd63f93709d0 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…PU hotplug lock BugLink: https://bugs.launchpad.net/bugs/2122432 resctrl takes the read side CPU hotplug lock whenever it is working with the list of domains. This prevents a CPU being brought online and the list being modified while resctrl is walking the list, or picking CPUs from the CPU masks. If resctrl domains for CPU-less NUMA nodes are to be supported, this would not be enough to prevent the domain list form being modified as a NUMA node can come online with only memory. Take the memory hotplug lock whenever the CPU hotplug lock is taken. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit f5a082989a5f40b9b95515d68b230f8125648fdb https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…arch stubs BugLink: https://bugs.launchpad.net/bugs/2122432 Resctrl expects the domain IDs for the 'MB' resource to be the corresponding L3 cache-ids. This is a problem for platforms where the memory bandwidth controls are implemented somewhere other than the L3 cache, and exist on a platform with CPU-less NUMA nodes. Such platforms can't currently be exposed via resctrl as not all the memory bandwidth can be controlled. Add a mount option to allow user-space to opt-in to the domain IDs for the MB resource to be the NUMA nid instead. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit ae8929caac02dccdc932666c1d8c906dda541bf1 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 idx is not used. Remove it to avoid build warning. The author is James but he doesn't add his Signed-off-by. (backported from commit c9b4fabe0b1b4805186d4326d47547993a02d191 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) [fenghuay: Change subject to a meaningfull one. Add commit message.] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…stead of cache-id BugLink: https://bugs.launchpad.net/bugs/2122432 The MB domain ids are the L3 cache-id. This is unfortunate if the memory bandwidth controls are implemented for CPU-less NUMA nodes as there is no L3 whose cache-id can be used to expose these controls to resctrl. When picking the class to use as MB, note whether it is possible for the NUMA nid to be used as the domain-id. By default the MB resource will use the cache-id. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit c2506e7fdb9e9de624af635f5060a1fe56a6bb80 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
… work with a set of CPUs BugLink: https://bugs.launchpad.net/bugs/2122432 mpam_resctrl_offline_domain_hdr() expects to take a single CPU that is going offline. Once all CPUs are offline, the domain header is removed from its parent list, and the structure can be freed. This doesn't work for NUMA nodes. Change the CPU passed to mpam_resctrl_offline_domain_hdr() and mpam_resctrl_domain_hdr_init to be a cpumask. This allows a single CPU to be passed for CPUs going offline, and cpu_possible_mask to be passed for a NUMA node going offline. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 093483e5bca0aef546208b32eedf59f3aac665ff https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…domain() to have CPU and node BugLink: https://bugs.launchpad.net/bugs/2122432 mpam_resctrl_alloc_domain() brings a domain with CPUs online. To allow for domains that don't have any CPUs, split it into a CPU and NUMA node version. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit 817d04bd296871b61dd70f68d160b85837dfe9a8 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…nline/offline BugLink: https://bugs.launchpad.net/bugs/2122432 To expose resctrl resources that contain CPU-less NUMA domains, resctrl needs to be told when a CPU-less NUMA domain comes online. This can't be done with the cpuhp callbacks. Add a memory hotplug notifier, and use this to create and destroy resctrl domains. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit caf4034229d8df2c306658c2ddbe3c1ab73df109 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…UMA nid as MB domain-id BugLink: https://bugs.launchpad.net/bugs/2122432 Enable resctrl's use of NUMA nid as the domain-id for the MB resource. Changing this state involves changing the IDs of all the domains visible to resctrl. Writing to this list means preventing CPU and memory hotplug. Signed-off-by: James Morse <james.morse@arm.com> (cherry picked from commit a795ac909c6c050daaf095abc9043217ddf5e746 https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git) Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 Modified for latest MPAM. Signed-off-by: Brad Figg <bfigg@nvidia.com> Signed-off-by: Koba Ko <kobak@nvidia.com> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> (forward ported from commit 77bd02c https://github.com/NVIDIA/NV-Kernels/tree/24.04_linux-nvidia-6.14-next) [fenghuay: change 6.14 path to 6.17] Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Matt Ochs <mochs@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> Acked-by: Koba Ko <kobak@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 Define the missing SHIFT definitions to fix build errors. Fixes: a76ea20 ("NVIDIA: SAUCE: arm_mpam: Add quirk framework") Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 partid is from 0 to partid_max, inclusively. partid_max + 1 is out of valid partid range. Accessing partid_max + 1 will generate error interrupt and cause MPAM disabled. Signed-off-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…ed in mbm_event mode BugLink: https://bugs.launchpad.net/bugs/2122432 The following NULL pointer dereference is encountered on mount of resctrl fs after booting a system that supports assignable counters with the "rdt=!mbmtotal,!mbmlocal" kernel parameters: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:mbm_cntr_get Call Trace: rdtgroup_assign_cntr_event rdtgroup_assign_cntrs rdt_get_tree Specifying the kernel parameter "rdt=!mbmtotal,!mbmlocal" effectively disables the legacy X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL features and the MBM events they represent. This results in the per-domain MBM event related data structures to not be allocated during early initialization. resctrl fs initialization follows by implicitly enabling both MBM total and local events on a system that supports assignable counters (mbm_event mode), but this enabling occurs after the per-domain data structures have been created. After booting, resctrl fs assumes that an enabled event can access all its state. This results in NULL pointer dereference when resctrl attempts to access the un-allocated structures of an enabled event. Remove the late MBM event enabling from resctrl fs. This leaves a problem where the X86_FEATURE_CQM_MBM_TOTAL and X86_FEATURE_CQM_MBM_LOCAL features may be disabled while assignable counter (mbm_event) mode is enabled without any events to support. Switching between the "default" and "mbm_event" mode without any events is not practical. Create a dependency between the X86_FEATURE_{CQM_MBM_TOTAL,CQM_MBM_LOCAL} and X86_FEATURE_ABMC (assignable counter) hardware features. An x86 system that supports assignable counters now requires support of X86_FEATURE_CQM_MBM_TOTAL or X86_FEATURE_CQM_MBM_LOCAL. This ensures all needed MBM related data structures are created before use and that it is only possible to switch between "default" and "mbm_event" mode when the same events are available in both modes. This dependency does not exist in the hardware but this usage of these feature settings work for known systems. [ bp: Massage commit message. ] Fixes: 1339086 ("x86,fs/resctrl: Detect Assignable Bandwidth Monitoring feature details") Co-developed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://patch.msgid.link/a62e6ac063d0693475615edd213d5be5e55443e6.1760560934.git.babu.moger@amd.com (cherry picked from commit 19de711) Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 Add 'CONFIG_ARM64_MPAM_RESCTRL_FS' to annotations. No code yet exits for 'CONFIG_CGROUP_RESCTRL' and 'CONFIG_RESCTRL_PMU', remove them from annotations. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2122432 KUNIT_CASE_PARAM macro's parameter generator function expects signature 'const void* gen_params(const void *prev, char *desc)' but function test_all_bwa_wd_gen_params() has wrong signature, causing compilation failure. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…it alignment fault BugLink: https://bugs.launchpad.net/bugs/2122432 KUnit builds pack struct mpam_props, which can misalign its DECLARE_BITMAP (features). On arm64, bitops perform unsigned long accesses that fault on misaligned addresses, causing mpam_resctrl KUnit tests to abort (EC=0x25 DABT, FSC=0x21 alignment fault). Keep the struct packed (to preserve padding-sanitization intent) but force its alignment to __alignof__(unsigned long) so bitmap operations are naturally aligned. No functional change outside tests. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
…ytes of mpam_props BugLink: https://bugs.launchpad.net/bugs/2122432 Aligning struct mpam_props introduces potential tail padding beyond the last field. The test previously used memcmp over the entire struct, which now fails due to padding differences rather than content. Compare only up to the last meaningful field (via offsetof + sizeof) to avoid false negatives. No behavioral change to driver logic. Signed-off-by: Tushar Dave <tdave@nvidia.com> Acked-by: Jamie Nguyen <jamien@nvidia.com> Acked-by: Matthew R. Ochs <mochs@nvidia.com> Acked-by: Noah Wager <noah.wager@canonical.com>
Ignore: yes Signed-off-by: Ian May <ianm@nvidia.com> Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…ERIC_ARCH_TOPOLOGY The arm_pmu driver is using topology_core_has_smt() for retrieving the SMT implementation which depends on CONFIG_GENERIC_ARCH_TOPOLOGY. The config is optional on arm platforms so provide a !CONFIG_GENERIC_ARCH_TOPOLOGY stub for topology_core_has_smt(). Fixes: c3d78c3 ("perf: arm_pmuv3: Don't use PMCCNTR_EL0 on SMT cores") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511041757.vuCGOmFc-lkp@intel.com/ Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Yicong Yang <yangyccccc@gmail.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> (cherry picked from commit 7ab06ea) Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
nvmochs
approved these changes
Jan 14, 2026
Collaborator
nvmochs
left a comment
nvmochs
left a comment
There was a problem hiding this comment.
This isn't really needed in our kernel since we have that kconfig, but doesn't hurt to add it. Verified the patch matches upstream.
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
clsotog
approved these changes
Jan 14, 2026
Collaborator
clsotog
left a comment
clsotog
left a comment
There was a problem hiding this comment.
Acked-by: Carol L Soto <csoto@nvidia.com>
nvidia-bfigg
force-pushed
the
24.04_linux-nvidia-6.17-next
branch
from
021c218 to
899b59a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
backport a patch that fixes "c3d78c34ad00 ("perf: arm_pmuv3: Don't use PMCCNTR_EL0 on SMT cores")"
LP:https://bugs.launchpad.net/ubuntu/+source/linux-nvidia/+bug/2138375