[linux-nvidia-6.18-next] July UNSAUCE#494
Closed
ltrager wants to merge 407 commits into
Closed
Conversation
When features are mismatched between MSC the way features are combined to the class determines whether resctrl can support this SoC. Add some tests to illustrate the sort of thing that is expected to work, and those that must be removed. Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Fenghua Yu <fenghuay@nvidia.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Fenghua Yu <fenghuay@nvidia.com> Tested-by: Carl Worth <carl@os.amperecomputing.com> Tested-by: Gavin Shan <gshan@redhat.com> Tested-by: Zeng Heng <zengheng4@huawei.com> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Tested-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 2557e0e) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Create a maintainer entry for the new MPAM Driver. Add myself and James Morse as maintainers. James created the driver and I have taken up the later versions of his series. Cc: James Morse <james.morse@arm.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit ce1e142) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Every resctrl resource has a list of domain structures. struct rdt_ctrl_domain and struct rdt_mon_domain both begin with struct rdt_domain_hdr with rdt_domain_hdr::type used in validity checks before accessing the domain of a particular type. Add the resource id to struct rdt_domain_hdr in preparation for a new monitoring domain structure that will be associated with a new monitoring resource. Improve existing domain validity checks with a new helper domain_header_is_valid() that checks both domain type and resource id. domain_header_is_valid() should be used before every call to container_of() that accesses a domain structure. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 03eb578) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Carve out the resource monitoring domain init code into a separate helper in order to be able to initialize new types of monitoring domains besides the usual L3 ones. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 0d64476) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
New telemetry events will be associated with a new package scoped resource with a new domain structure. Refactor domain_remove_cpu_mon() so all the L3 domain processing is separate from the general domain action of clearing the CPU bit in the mask. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 6396fc5) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
For symmetry with domain_remove_cpu_mon() refactor domain_remove_cpu_ctrl() to take an early return when removing a CPU does not empty the domain. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit c1b6305) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
…_hdr Up until now, all monitoring events were associated with the L3 resource and it made sense to use the L3 specific "struct rdt_mon_domain *" argument to functions operating on domains. Telemetry events will be tied to a new resource with its instances represented by a new domain structure that, just like struct rdt_mon_domain, starts with the generic struct rdt_domain_hdr. Prepare to support domains belonging to different resources by changing the calling convention of functions operating on domains. Pass the generic header and use that to find the domain specific structure where needed. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 97fec06) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Carve out the L3 resource specific event reading code into a separate helper to support reading event data from a new monitoring resource. Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit ad5c2ff) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Convert the whole call sequence from mon_event_read() to resctrl_arch_rmid_read() to pass resource independent struct rdt_domain_hdr instead of an L3 specific domain structure to prepare for monitoring events in other resources. This additional layer of indirection obscures which aspects of event counting depend on a valid domain. Event initialization, support for assignable counters, and normal event counting implicitly depend on a valid domain while summing of domains does not. Split summing domains from the core event counting handling to make their respective dependencies obvious. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 6b10cf7) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
The upcoming telemetry event monitoring is not tied to the L3 resource and will have a new domain structure. Rename the L3 resource specific domain data structures to include "l3_" in their names to avoid confusion between the different resource specific domain structures: rdt_mon_domain -> rdt_l3_mon_domain rdt_hw_mon_domain -> rdt_hw_l3_mon_domain No functional change. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 4bc3ef4) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
With the arrival of monitor events tied to new domains associated with a different resource it would be clearer if the L3 resource specific functions are more accurately named. Rename three groups of functions: Functions that allocate/free architecture per-RMID MBM state information: arch_domain_mbm_alloc() -> l3_mon_domain_mbm_alloc() mon_domain_free() -> l3_mon_domain_free() Functions that allocate/free filesystem per-RMID MBM state information: domain_setup_mon_state() -> domain_setup_l3_mon_state() domain_destroy_mon_state() -> domain_destroy_l3_mon_state() Initialization/exit: rdt_get_mon_l3_config() -> rdt_get_l3_mon_config() resctrl_mon_resource_init() -> resctrl_l3_mon_resource_init() resctrl_mon_resource_exit() -> resctrl_l3_mon_resource_exit() Ensure kernel-doc descriptions of these functions' return values are present and correctly formatted. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 9c214d1) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
…vents Reading monitoring event data from MMIO requires more context than the event id to be able to read the correct memory location. struct mon_evt is the appropriate place for this event specific context. Prepare for addition of extra fields to struct mon_evt by changing the calling conventions to pass a pointer to the mon_evt structure instead of just the event id. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit dd11088) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
resctrl assumes that monitor events can only be read from a CPU in the cpumask_t set of each domain. This is true for x86 events accessed with an MSR interface, but may not be true for other access methods such as MMIO. Introduce and use flag mon_evt::any_cpu, settable by architecture, that indicates there are no restrictions on which CPU can read that event. This flag is not supported by the L3 event reading that requires to be run on a CPU that belongs to the L3 domain of the event being read. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit ab0308a) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
resctrl assumes that all monitor events can be displayed as unsigned decimal
integers.
Hardware architecture counters may provide some telemetry events with greater
precision where the event is not a simple count, but is a measurement of some
sort (e.g. Joules for energy consumed).
Add a new argument to resctrl_enable_mon_event() for architecture code to
inform the file system that the value for a counter is a fixed-point value
with a specific number of binary places.
Only allow architecture to use floating point format on events that the file
system has marked with mon_evt::is_floating_point which reflects the contract
with user space on how the event values are displayed.
Display fixed point values with values rounded to ceil(binary_bits * log10(2))
decimal places. Special case for zero binary bits to print "{value}.0".
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com
(cherry picked from commit e37c9a3)
Signed-off-by: Lee Trager <ltrager@nvidia.com>
Acked-by: Andrea Righi <arighi@nvidia.com>
Acked-by: Fenghua Yu <fenghuay@nvidia.com>
Acked-by: Seth Forshee <sforshee@nvidia.com>
Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Enumeration of Intel telemetry events is an asynchronous process involving several mutually dependent drivers added as auxiliary devices during the device_initcall() phase of Linux boot. The process finishes after the probe functions of these drivers completes. But this happens after resctrl_arch_late_init() is executed. Tracing the enumeration process shows that it does complete a full seven seconds before the earliest possible mount of the resctrl file system (when included in /etc/fstab for automatic mount by systemd). Add a hook for use by telemetry event enumeration and initialization and run it once at the beginning of resctrl mount without any locks held. The architecture is responsible for any required locking. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20260105191711.GBaVwON5nZn-uO6Sqg@fat_crate.local (cherry picked from commit 39208e7) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
…oring Add a new PERF_PKG resource and introduce package level scope for monitoring telemetry events so that CPU hotplug notifiers can build domains at the package granularity. Use the physical package ID available via topology_physical_package_id() to identify the monitoring domains with package level scope. This enables user space to use: /sys/devices/system/cpu/cpuX/topology/physical_package_id to identify the monitoring domain a CPU is associated with. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 2e53ad6) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
…ming domains The feature to sum event data across multiple domains supports systems with Sub-NUMA Cluster (SNC) mode enabled. The top-level monitoring files in each "mon_L3_XX" directory provide the sum of data across all SNC nodes sharing an L3 cache instance while the "mon_sub_L3_YY" sub-directories provide the event data of the individual nodes. SNC is only associated with the L3 resource and domains and as a result the flow handling the sum of event data implicitly assumes it is working with the L3 resource and domains. Reading of telemetry events does not require to sum event data so this feature can remain dedicated to SNC and keep the implicit assumption of working with the L3 resource and domains. Add a WARN to where the implicit assumption of working with the L3 resource is made and add comments on how the structure controlling the event sum feature is used. Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit db64994) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Each CPU collects data for telemetry events that it sends to the nearest
telemetry event aggregator either when the value of MSR_IA32_PQR_ASSOC.RMID
changes, or when a two millisecond timer expires.
There is a feature type ("energy" or "perf"), GUID, and MMIO region associated
with each aggregator. This combination links to an XML description of the
set of telemetry events tracked by the aggregator. XML files are published
by Intel in a GitHub repository¹.
The telemetry event aggregators maintain per-RMID per-event counts of the
total seen for all the CPUs. There may be multiple telemetry event aggregators
per package.
There are separate sets of aggregators for each feature type. Aggregators
in a set may have different GUIDs. All aggregators with the same feature
type and GUID are symmetric keeping counts for the same set of events for
the CPUs that provide data to them.
The XML file for each aggregator provides the following information:
0) Feature type of the events ("perf" or "energy")
1) Which telemetry events are tracked by the aggregator.
2) The order in which the event counters appear for each RMID.
3) The value type of each event counter (integer or fixed-point).
4) The number of RMIDs supported.
5) Which additional aggregator status registers are included.
6) The total size of the MMIO region for an aggregator.
Introduce struct event_group that condenses the relevant information from
an XML file. Hereafter an "event group" refers to a group of events of a
particular feature type (event_group::pfname set to "energy" or "perf") with
a particular GUID.
Use event_group::pfname to determine the feature id needed to obtain the
aggregator details. It will later be used in console messages and with the
rdt= boot parameter.
The INTEL_PMT_TELEMETRY driver enumerates support for telemetry events.
This driver provides intel_pmt_get_regions_by_feature() to list all available
telemetry event aggregators of a given feature type. The list includes the
"guid", the base address in MMIO space for the region where the event counters
are exposed, and the package id where the all the CPUs that report to this
aggregator are located.
Call INTEL_PMT_TELEMETRY's intel_pmt_get_regions_by_feature() for each event
group to obtain a private copy of that event group's aggregator data. Duplicate
the aggregator data between event groups that have the same feature type
but different GUID. Further processing on this private copy will be unique
to the event group.
¹https://github.com/intel/Intel-PMT
[ bp: Zap text explaining the code, s/guid/GUID/g ]
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com
(cherry picked from commit 1fb2daa)
Signed-off-by: Lee Trager <ltrager@nvidia.com>
Acked-by: Andrea Righi <arighi@nvidia.com>
Acked-by: Fenghua Yu <fenghuay@nvidia.com>
Acked-by: Seth Forshee <sforshee@nvidia.com>
Signed-off-by: Seth Forshee <sforshee@nvidia.com>
…GUIDs The telemetry event aggregators of the Intel Clearwater Forest CPU support two RMID-based feature types: "energy" with GUID 0x26696143¹, and "perf" with GUID 0x26557651². The event counter offsets in an aggregator's MMIO space are arranged in groups for each RMID. E.g., the "energy" counters for GUID 0x26696143 are arranged like this: MMIO offset:0x0000 Counter for RMID 0 PMT_EVENT_ENERGY MMIO offset:0x0008 Counter for RMID 0 PMT_EVENT_ACTIVITY MMIO offset:0x0010 Counter for RMID 1 PMT_EVENT_ENERGY MMIO offset:0x0018 Counter for RMID 1 PMT_EVENT_ACTIVITY ... MMIO offset:0x23F0 Counter for RMID 575 PMT_EVENT_ENERGY MMIO offset:0x23F8 Counter for RMID 575 PMT_EVENT_ACTIVITY After all counters there are three status registers that provide indications of how many times an aggregator was unable to process event counts, the time stamp for the most recent loss of data, and the time stamp of the most recent successful update. MMIO offset:0x2400 AGG_DATA_LOSS_COUNT MMIO offset:0x2408 AGG_DATA_LOSS_TIMESTAMP MMIO offset:0x2410 LAST_UPDATE_TIMESTAMP Define event_group structures for both of these aggregator types and define the events tracked by the aggregators in the file system code. PMT_EVENT_ENERGY and PMT_EVENT_ACTIVITY are produced in fixed point format. File system code must output as floating point values. ¹https://github.com/intel/Intel-PMT/blob/main/xml/CWF/OOBMSM/RMID-ENERGY/cwf_aggregator.xml ²https://github.com/intel/Intel-PMT/blob/main/xml/CWF/OOBMSM/RMID-PERF/cwf_aggregator.xml [ bp: Massage commit message. ] Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 8f6b6ad) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
The resctrl file system layer passes the domain, RMID, and event id to the architecture to fetch an event counter. Fetching a telemetry event counter requires additional information that is private to the architecture, for example, the offset into MMIO space from where the counter should be read. Add mon_evt::arch_priv that architecture can use for any private data related to the event. The resctrl filesystem initializes mon_evt::arch_priv when the architecture enables the event and passes it back to architecture when needing to fetch an event counter. Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 8ccb1f8) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Every event group has a private copy of the data of all telemetry event aggregators (aka "telemetry regions") tracking its feature type. Included may be regions that have the same feature type but tracking different GUID from the event group's. Traverse the event group's telemetry region data and mark all regions that are not usable by the event group as unusable by clearing those regions' MMIO addresses. A region is considered unusable if: 1) GUID does not match the GUID of the event group. 2) Package ID is invalid. 3) The enumerated size of the MMIO region does not match the expected value from the XML description file. Hereafter any telemetry region with an MMIO address is considered valid for the event group it is associated with. Enable all the event group's events as long as there is at least one usable region from where data for its events can be read. Enabling of an event can fail if the same event has already been enabled as part of another event group. It should never happen that the same event is described by different GUID supported by the same system so just WARN (via resctrl_enable_mon_event()) and skip the event. Note that it is architecturally possible that some telemetry events are only supported by a subset of the packages in the system. It is not expected that systems will ever do this. If they do the user will see event files in resctrl that always return "Unavailable". Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 7e6df96) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Introduce intel_aet_read_event() to read telemetry events for resource RDT_RESOURCE_PERF_PKG. There may be multiple aggregators tracking each package, so scan all of them and add up all counters. Aggregators may return an invalid data indication if they have received no records for a given RMID. The user will see "Unavailable" if none of the aggregators on a package provide valid counts. Resctrl now uses readq() so depends on X86_64. Update Kconfig. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 51541f6) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Population of a monitor group's mon_data directory is unreasonably complicated because of the support for Sub-NUMA Cluster (SNC) mode. Split out the SNC code into a helper function to make it easier to add support for a new telemetry resource. Move all the duplicated code to make and set owner of domain directories into the mon_add_all_files() helper and rename to _mkdir_mondata_subdir(). Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 0ec1db4) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Clearing a monitor group's mon_data directory is complicated because of the support for Sub-NUMA Cluster (SNC) mode. Refactor the SNC case into a helper function to make it easier to add support for a new telemetry resource. Suggested-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 93d9fd8) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
…_PKG The L3 resource has several requirements for domains. There are per-domain structures that hold the 64-bit values of counters, and elements to keep track of the overflow and limbo threads. None of these are needed for the PERF_PKG resource. The hardware counters are wide enough that they do not wrap around for decades. Define a new rdt_perf_pkg_mon_domain structure which just consists of the standard rdt_domain_hdr to keep track of domain id and CPU mask. Update resctrl_online_mon_domain() for RDT_RESOURCE_PERF_PKG. The only action needed for this resource is to create and populate domain directories if a domain is added while resctrl is mounted. Similarly resctrl_offline_mon_domain() only needs to remove domain directories. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit f4e0cd8) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Legacy resctrl features are enumerated by X86_FEATURE_* flags. These may be overridden by quirks to disable features in the case of errata. Users can use kernel command line options to either disable a feature, or to force enable a feature that was disabled by a quirk. A different approach is needed for hardware features that do not have an X86_FEATURE_* flag. Update parsing of the "rdt=" boot parameter to call the telemetry driver directly to handle new "perf" and "energy" options that controls activation of telemetry monitoring of the named type. By itself a "perf" or "energy" option controls the forced enabling or disabling (with ! prefix) of all event groups of the named type. A ":guid" suffix allows for fine grained control per event group. [ bp: s/intel_aet_option/intel_handle_aet_option/g ] Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 842e7f9) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
There are now three meanings for "number of RMIDs": 1) The number for legacy features enumerated by CPUID leaf 0xF. This is the maximum number of distinct values that can be loaded into MSR_IA32_PQR_ASSOC. Note that systems with Sub-NUMA Cluster mode enabled will force scaling down the CPUID enumerated value by the number of SNC nodes per L3-cache. 2) The number of registers in MMIO space for each event. This is enumerated in the XML files and is the value initialized into event_group::num_rmid. 3) The number of "hardware counters" (this isn't a strictly accurate description of how things work, but serves as a useful analogy that does describe the limitations) feeding to those MMIO registers. This is enumerated in telemetry_region::num_rmids returned by intel_pmt_get_regions_by_feature(). Event groups with insufficient "hardware counters" to track all RMIDs are difficult for users to use, since the system may reassign "hardware counters" at any time. This means that users cannot reliably collect two consecutive event counts to compute the rate at which events are occurring. Disable such event groups by default. The user may override this with a command line "rdt=" option. In this case limit an under-resourced event group's number of possible monitor resource groups to the lowest number of "hardware counters". Scan all enabled event groups and assign the RDT_RESOURCE_PERF_PKG resource "num_rmid" value to the smallest of these values as this value will be used later to compare against the number of RMIDs supported by other resources to determine how many monitoring resource groups are supported. N.B. Change type of resctrl_mon::num_rmid to u32 to match its usage and the type of event_group::num_rmid so that min(r->num_rmid, e->num_rmid) won't complain about mixing signed and unsigned types. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 67640e3) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
closid_num_dirty_rmid[] and rmid_ptrs[] are allocated together during resctrl initialization and freed together during resctrl exit. Telemetry events are enumerated on resctrl mount so only at resctrl mount will the number of RMID supported by all monitoring resources and needed as size for rmid_ptrs[] be known. Separate closid_num_dirty_rmid[] and rmid_ptrs[] allocation and free in preparation for rmid_ptrs[] to be allocated on resctrl mount. Keep the rdtgroup_mutex protection around the allocation and free of closid_num_dirty_rmid[] as ARM needs this to guarantee memory ordering. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit ee7f6af) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
resctrl assumes that only the L3 resource supports monitor events, so it simply takes the rdt_resource::num_rmid from RDT_RESOURCE_L3 as the system's number of RMIDs. The addition of telemetry events in a different resource breaks that assumption. Compute the number of available RMIDs as the minimum value across all mon_capable resources (analogous to how the number of CLOSIDs is computed across alloc_capable resources). Note that mount time enumeration of the telemetry resource means that this number can be reduced. If this happens, then some memory will be wasted as the allocations for rdt_l3_mon_domain::mbm_states[] and rdt_l3_mon_domain::rmid_busy_llc created during resctrl initialization will be larger than needed. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit 0ecc988) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
L3 monitor features are enumerated during resctrl initialization and rmid_ptrs[] that tracks all RMIDs and depends on the number of supported RMIDs is allocated during this time. Telemetry monitor features are enumerated during first resctrl mount and may support a different number of RMIDs compared to L3 monitor features. Delay allocation and initialization of rmid_ptrs[] until first mount. Since the number of RMIDs cannot change on later mounts, keep the same set of rmid_ptrs[] until resctrl_exit(). This is required because the limbo handler keeps running after resctrl is unmounted and needs to access rmid_ptrs[] as it keeps tracking busy RMIDs after unmount. Rename routines to match what they now do: dom_data_init() -> setup_rmid_lru_list() dom_data_exit() -> free_rmid_lru_list() Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com (cherry picked from commit d089164) Signed-off-by: Lee Trager <ltrager@nvidia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Fenghua Yu <fenghuay@nvidia.com> Acked-by: Seth Forshee <sforshee@nvidia.com> Signed-off-by: Seth Forshee <sforshee@nvidia.com>
Replace the per-instance DVC/VI boolean flags with a tegra_i2c_variant enum and move the variant field into tegra_i2c_hw_feature so it is populated via SoC match data. Add dedicated SoC data entries for the "nvidia,tegra20-i2c-dvc" and "nvidia,tegra210-i2c-vi" compatibles and drop compatible-string checks from tegra_i2c_parse_dt. Suggested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260324055843.549808-2-kkartik@nvidia.com (cherry picked from commit 4eeb19a) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Tegra410 use different offsets for existing I2C registers, update the logic to use appropriate offsets per SoC. As the register offsets are now defined in the SoC-specific tegra_i2c_regs structures, the tegra_i2c_reg_addr() function is no longer needed to translate register offsets and has been removed. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260324055843.549808-3-kkartik@nvidia.com (cherry picked from commit 0c0e440) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Add support for the Tegra410 SoC, which has 4 I2C controllers. The controllers are feature-equivalent to Tegra264; only the register offsets differ. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260324055843.549808-4-kkartik@nvidia.com (cherry picked from commit 59717f2) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Extract the QoS-related logic from cpufreq_policy_online() to make that function shorter/simpler. The logic is placed in cpufreq_policy_init_qos() and is now executed right after the following calls: - cpufreq_driver->init() - cpufreq_table_validate_and_sort() This facilitats subsequent changes that will, in cpufreq_policy_init_qos(): - Set a default policy->min/max value for all policies. - Use the policy->min/max values set by drivers as initial request values for policy frequency QoS requests. No functional change. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com> [ rjw: Changelog edits ] Link: https://patch.msgid.link/20260528090913.2759118-2-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 70fa8a1) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Some drivers set policy->min/max in their .init() callback, but
cpufreq_set_policy() will ultimately override them through:
cpufreq_policy_online()
\-cpufreq_init_policy()
\-cpufreq_set_policy()
\-/* Set policy->min/max */
Thus the policy min/max values set by the drivers are only temporary.
There is an exception if CPUFREQ_NEED_INITIAL_FREQ_CHECK is set and
cpufreq_policy_online() calls __cpufreq_driver_target() which invokes
cpufreq_driver->target().
To prepare for a subsequent change that will remove all initialization
of policy->min/max in driver .init() callbacks if the min/max value is
equal to the corresponding cpuinfo.min/max_freq, set default
policy->min/max values in the core for all drivers.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
[ rjw: Edits of the new comment and changelog ]
Link: https://patch.msgid.link/20260528090913.2759118-3-pierre.gondois@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 743a3cd)
Signed-off-by: Lee Trager <ltrager@nvidia.com>
Collaborator
BaseOS Kernel ReviewSummaryNo issues found across the reviewed commits. Findings: no problems found Latest watcher review: open review Generated test plan: open test plan Kernel deb build: successful (download debs, 4 files) Head: This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review. |
Collaborator
|
Build break for This commit reapplies upstream policy->cpuinfo.max_freq = cpudata->max_freq;Upstream can read Building the PR head ( This affects the amd64 flavours, which build amd-pstate with The reverted policy->cpuinfo.max_freq = perf_to_freq(perf, cpudata->nominal_freq, perf.highest_perf);The commit trailer records that the divergence was resolved toward upstream:
Two ways to resolve:
The |
Collaborator
|
I got similar comments like Jamie. |
The value of maximum frequency is fixed and never changes. Doing calculations every time based off of perf is unnecessary. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20260326193620.649441-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> (cherry picked from commit 8cdc494) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Prior to commit 521223d ("cpufreq: Fix initialization of min and max frequency QoS requests"), drivers were setting policy->min/max and these values were used as initial policy QoS constraints. After the above commit, these values are only used temporarily, as cpufreq_set_policy() ultimately overrides them through: cpufreq_policy_online() \-cpufreq_init_policy() \-cpufreq_set_policy() \-/* Set policy->min/max */ A subsequent change will restore the previous behavior allowing drivers to request special min/max QoS frequencies instead of FREQ_QOS_MIN_DEFAULT_VALUE and FREQ_QOS_MAX_DEFAULT_VALUE, respectively, if desired. For instance, the CPPC driver wants to advertise the lowest non-linear frequency that should be used as the initial minimum frequency QoS request. However, for this purpose, all drivers setting policy->min/max to policy->cpuinfo.min/max_freq, respectively, need to be updated so their initial policy->min/max settings don't limit the frequency scaling unnecessarily going forward (which would defeat the purpose of commit 521223d), so do that. This does not actually alter the observed behavior of all of the drivers in question because setting policy->min/max to policy->cpuinfo.min/max_freq, respectively, is not necessary or even useful any more after a previous change ("cpufreq: Set default policy->min/max values for all drivers"). Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Acked-by: Jie Zhan <zhanjie9@hisilicon.com> [ rjw: Changelog rewrite ] Link: https://patch.msgid.link/20260528090913.2759118-4-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit db80ad7) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Modify cpufreq_policy_init_qos() introduced previously to use policy->min/max set in the driver .init() callback as the initial values for the policy min/max frequency QoS requests, respectively, so long as they are different from 0 (which means that they have been updated by the driver). Update the documentation in accordance with that code change. This only affects the following drivers: - gx-suspmod (min) - cppc-cpufreq (min) - longrun (min/max) Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> [ rjw: Changelog rewrite ] Link: https://patch.msgid.link/20260528090913.2759118-5-pierre.gondois@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 8c83947) Signed-off-by: Lee Trager <ltrager@nvidia.com>
FFA_FEATURES reports the minimum size and alignment boundary required for RXTX_MAP. In FF-A v1.2 and later it can also report a maximum buffer size, with zero meaning that no maximum is enforced. The driver only used the minimum value and then rounded it up to PAGE_SIZE before invoking RXTX_MAP after commit 8321025 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP"). On systems where PAGE_SIZE is larger than the advertised minimum, this can exceed a non-zero maximum reported by firmware. Older implementations do not advertise a maximum and may also reject the rounded-up size. Decode the maximum size and clamp the page-aligned minimum to it when it is present. If no maximum is advertised and RXTX_MAP rejects the rounded size with INVALID_PARAMETERS, retry with the advertised minimum size. Record drv_info->rxtx_bufsz only after RXTX_MAP succeeds so it reflects the size registered with firmware. While there, also update RXTX_MAP_MIN_BUFSZ() to use FIELD_GET() for consistency. Fixes: 8321025 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP") Suggested-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Seth Forshee <sforshee@nvidia.com> Link: https://patch.msgid.link/20260602-b4-ffa-rxtx-map-fixes-v2-1-7cb06508da84@nvidia.com (sudeep.holla: Minor rewording subject and commit message) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> (cherry picked from commit 53716a4) Signed-off-by: Lee Trager <ltrager@nvidia.com>
Collaborator
|
|
Collaborator
Author
|
Looks like I missed the upstream prerequisite NVIDIA/nvidia-kernel-patches-verification#14 adds 8cdc494 (cpufreq/amd-pstate: Cache the max frequency in cpudata)` to the nvidia-kernel-patches-verification tool |
ltrager
marked this pull request as ready for review
July 21, 2026 00:01
clsotog
approved these changes
Jul 21, 2026
clsotog
left a comment
clsotog
left a comment
Collaborator
There was a problem hiding this comment.
Acked-by: Carol L Soto <csoto@nvidia.com>
nirmoy
added
has_2_acks
and removed
help wanted
ltrager
force-pushed
the
linux-nvidia-6.18-next
branch
from
July 21, 2026 19:41
648f3c9 to
0cd3bc7
Compare
Collaborator
Author
|
All patches have been replaced in |
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
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.
Overview
The following patches SAUCE patches have been upstreamed and accepted into Linus's tree. Revert the SAUCE version and apply Linus's version in
linux-nvidia-6.18-next. The nvidia-kernel-patches-verification tool had the correct hash for all but one patch which is corrected in NVIDIA/nvidia-kernel-patches-verification#12When approved I will drop the original patches instead of having a revert commit.
Testing
Build and boot on a Vera system