* [PATCH v3 01/12] x86/resctrl: Support Privilege-Level Zero Association (PLZA)
From: Babu Moger @ 2026-04-30 23:24 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, bp, dave.hansen
Cc: skhan, x86, babu.moger, mingo, hpa, akpm, rdunlap,
pawan.kumar.gupta, feng.tang, dapeng1.mi, kees, elver, lirongqing,
paulmck, bhelgaas, seanjc, alexandre.chartre, yazen.ghannam,
peterz, chang.seok.bae, kim.phillips, xin, naveen,
thomas.lendacky, linux-doc, linux-kernel, eranian, peternewman,
sos-linux-ext-patches
In-Reply-To: <cover.1777591496.git.babu.moger@amd.com>
Customers have identified an issue while using the QoS resource Control
feature. If a memory bandwidth associated with a CLOSID is aggressively
throttled, and it moves into Kernel mode, the Kernel operations are also
aggressively throttled. This can stall forward progress and eventually
degrade overall system performance. AMD hardware supports a feature
Privilege-Level Zero Association (PLZA) to change the association of the
thread as soon as it begins executing.
Privilege-Level Zero Association (PLZA) allows the user to specify a CLOSID
and/or RMID associated with execution in Privilege-Level Zero. When enabled
on a HW thread, when the thread enters Privilege-Level Zero, transactions
associated with that thread will be associated with the PLZA CLOSID and/or
RMID. Otherwise, the HW thread will be associated with the CLOSID and RMID
identified by PQR_ASSOC.
Add PLZA support to resctrl and introduce a kernel parameter that allows
enabling or disabling the feature at boot time.
The GLBE feature details are documented in:
AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:
Publication # 69193 Revision: 1.00, Issue Date: March 2026
available at https://bugzilla.kernel.org/show_bug.cgi?id=206537
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v3: Code did not change. Patch order cahnged.
Added documentation link.
v2: Rebased on top of the latest tip.
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/resctrl/core.c | 2 ++
arch/x86/kernel/cpu/scattered.c | 1 +
4 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f2ce1f4975c1..3021c920f3e1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6463,7 +6463,7 @@ Kernel parameters
rdt= [HW,X86,RDT]
Turn on/off individual RDT features. List is:
cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
- mba, smba, bmec, abmc, sdciae, energy[:guid],
+ mba, smba, bmec, abmc, sdciae, plza, energy[:guid],
perf[:guid].
E.g. to turn on cmt and turn off mba use:
rdt=cmt,!mba
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 86d17b195e79..5739281bd4c7 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -515,6 +515,7 @@
* and purposes if CLEAR_CPU_BUF_VM is set).
*/
#define X86_FEATURE_X2AVIC_EXT (21*32+20) /* AMD SVM x2AVIC support for 4k vCPUs */
+#define X86_FEATURE_PLZA (21*32+21) /* Privilege-Level Zero Association */
/*
* BUG word(s)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 7667cf7c4e94..4a8717157e3e 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -799,6 +799,7 @@ enum {
RDT_FLAG_BMEC,
RDT_FLAG_ABMC,
RDT_FLAG_SDCIAE,
+ RDT_FLAG_PLZA,
};
#define RDT_OPT(idx, n, f) \
@@ -826,6 +827,7 @@ static struct rdt_options rdt_options[] __ro_after_init = {
RDT_OPT(RDT_FLAG_BMEC, "bmec", X86_FEATURE_BMEC),
RDT_OPT(RDT_FLAG_ABMC, "abmc", X86_FEATURE_ABMC),
RDT_OPT(RDT_FLAG_SDCIAE, "sdciae", X86_FEATURE_SDCIAE),
+ RDT_OPT(RDT_FLAG_PLZA, "plza", X86_FEATURE_PLZA),
};
#define NUM_RDT_OPTIONS ARRAY_SIZE(rdt_options)
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 837d6a4b0c28..630afb233194 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -60,6 +60,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_BMEC, CPUID_EBX, 3, 0x80000020, 0 },
{ X86_FEATURE_ABMC, CPUID_EBX, 5, 0x80000020, 0 },
{ X86_FEATURE_SDCIAE, CPUID_EBX, 6, 0x80000020, 0 },
+ { X86_FEATURE_PLZA, CPUID_EBX, 9, 0x80000020, 0 },
{ X86_FEATURE_TSA_SQ_NO, CPUID_ECX, 1, 0x80000021, 0 },
{ X86_FEATURE_TSA_L1_NO, CPUID_ECX, 2, 0x80000021, 0 },
{ X86_FEATURE_AMD_WORKLOAD_CLASS, CPUID_EAX, 22, 0x80000021, 0 },
--
2.43.0
^ permalink raw reply related
* [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Babu Moger @ 2026-04-30 23:24 UTC (permalink / raw)
To: corbet, tony.luck, reinette.chatre, Dave.Martin, james.morse,
tglx, bp, dave.hansen
Cc: skhan, x86, babu.moger, mingo, hpa, akpm, rdunlap,
pawan.kumar.gupta, feng.tang, dapeng1.mi, kees, elver, lirongqing,
paulmck, bhelgaas, seanjc, alexandre.chartre, yazen.ghannam,
peterz, chang.seok.bae, kim.phillips, xin, naveen,
thomas.lendacky, linux-doc, linux-kernel, eranian, peternewman,
sos-linux-ext-patches
Hi,
This series adds support for AMD's Privilege-Level Zero Association
(PLZA) so kernel work can be assigned to a resctrl group, and wires it
up through a small generic "kernel mode" (kmode) layer in fs/resctrl
so future architectures can plug in without touching core resctrl.
The features are documented in:
AMD64 Zen6 Platform Quality of Service (PQOS) Extensions,
Publication # 69193 Revision 1.00, Issue Date March 2026
available at https://bugzilla.kernel.org/show_bug.cgi?id=206537
The patches are based on top of commit (7.1.0-rc1)
Commit 3382329a309d Merge branch into tip/master: 'timers/clocksource'.
Background
==========
Customers have identified an issue while using the QoS resource Control
feature. If a memory bandwidth associated with a CLOSID is aggressively
throttled, and it moves into Kernel mode, the Kernel operations are also
aggressively throttled. This can stall forward progress and eventually
degrade overall system performance.
Privilege-Level Zero Association (PLZA) allows the user to specify a CLOSID
and/or RMID associated with execution in Privilege-Level Zero. When enabled
on a HW thread, when the thread enters Privilege-Level Zero, transactions
associated with that thread will be associated with the PLZA CLOSID and/or
RMID. Otherwise, the HW thread will be associated with the CLOSID and RMID
identified by PQR_ASSOC.
Design
======
A new sysfs file, info/kernel_mode, holds a single global policy that
selects what kernel work is steered and which rdtgroup it is steered
to. Reads describe the supported modes and the currently-active
binding; writes change the policy or rebind to a different group.
Look at the thread below for design discussion.
https://lore.kernel.org/lkml/14a8ad0a-e842-4268-871a-0762f1169e03@intel.com/
Per-rdtgroup files kmode_cpus and kmode_cpus_list scope the binding
to a subset of online CPUs without unbind/rebind churn. They are
visible only on the group that is currently the active kernel-mode
binding.
The arch hooks (resctrl_arch_get_kmode_support,
resctrl_arch_configure_kmode) keep the fs/resctrl layer arch-neutral.
Only AMD PLZA is wired up here; Intel and ARM can add their own
support later by implementing the hooks.
Layout
======
01-02 x86: PLZA CPU feature + MSR/data-structure plumbing.
03-05 fs/resctrl + x86: kmode data structures, arch hooks, and
population of supported modes.
06-08 fs/resctrl: global kmode config, info/kernel_mode read/write
and documentation.
09 fs/resctrl: reset the binding when the bound rdtgroup is
removed.
10-12 fs/resctrl: per-rdtgroup kmode_cpus[_list] - expose, gate
visibility on the bound group, and allow incremental writes.
Examples
========
(See Documentation/filesystems/resctrl.rst, "kernel_mode" and
"kmode_cpus" sections, for the full UAPI.)
# Mount resctrl
# mount -t resctrl resctrl /sys/fs/resctrl
# cd /sys/fs/resctrl
# Read the supported modes. The active mode is bracketed and reports
# the bound "<ctrl>/<mon>/" group; other supported modes report
# ":group=none" because nothing is bound to them.
# cat info/kernel_mode
[inherit_ctrl_and_mon:group=//]
global_assign_ctrl_inherit_mon_per_cpu:group=none
global_assign_ctrl_assign_mon_per_cpu:group=none
# Create a CTRL_MON group plus a MON child and bind both the kernel
# CLOSID and RMID to them.
# mkdir ctrl1
# mkdir ctrl1/mon_groups/mon1
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" \
> info/kernel_mode
# cat info/kernel_mode
inherit_ctrl_and_mon:group=none
global_assign_ctrl_inherit_mon_per_cpu:group=none
[global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
# kmode_cpus and kmode_cpus_list are visible only on the bound group.
# ls ctrl1/kmode_cpus*
ctrl1/kmode_cpus ctrl1/kmode_cpus_list
# Restrict the binding to a CPU subset; the write is incremental.
# echo 0-3 > ctrl1/kmode_cpus_list
# cat ctrl1/kmode_cpus
f
# cat ctrl1/kmode_cpus_list
0-3
# Empty masks are rejected; use info/kernel_mode to reset to
# "every online CPU".
# echo "" > ctrl1/kmode_cpus_list
bash: echo: write error: Invalid argument
# cat info/last_cmd_status
Empty mask not allowed; use info/kernel_mode to unbind
# Disable kernel-mode steering (back to inherit, default group).
# echo "inherit_ctrl_and_mon" > info/kernel_mode
Tested on AMD with PLZA; the generic bits build clean on x86 without
PLZA support and are no-ops at runtime.
Changelog
=========
v3:
- Generalise the layer beyond AMD: rename "PLZA mode" to "kernel
mode" (kmode) in code, sysfs, and Documentation. The public
interface is now info/kernel_mode and per-group kmode_cpus[_list].
- info/kernel_mode UAPI cleanups: ":group=none" instead of
":group=uninitialized"; designated initialisers + static_assert
for the mode-name table; strim() the input; clearer error
messages via last_cmd_status.
- kmode_cpus / kmode_cpus_list:
* 0010 exposes them read-only on every group.
* 0011 toggles their visibility via kernfs_show() so they
appear only on the rdtgroup currently bound to the active
kernel mode.
* 0012 (new) makes them writable: incremental
enable/disable deltas via resctrl_arch_configure_kmode(),
empty masks rejected with -EINVAL ("use info/kernel_mode
to unbind"), offline CPUs rejected, defensive -EBUSY for
stale fds opened before an info/kernel_mode rebind.
- 0009: reset the binding when the bound rdtgroup is removed,
instead of leaving stale state.
- Kerneldoc/comment cleanups across the series; Documentation
updated alongside the UAPI changes.
v2:
This is similar to RFC with new proposal. Names of the some interfaces
are not final. Lets fix that later as we move forward.
Separated the two features: Global Bandwidth Enforcement (GLBE) and
Privilege Level Zero Association (PLZA).
This series only adds support for PLZA.
Used the name of the feature as kmode instead of PLZA. That can be changed as well.
Tony suggested using global variables to store the kernel mode
CLOSID and RMID. However, the kernel mode CLOSID and RMID are
coming from rdtgroup structure with the new interface. Accessing
them requires holding the associated lock, which would make the
context switch path unnecessarily expensive. So, dropped the idea.
https://lore.kernel.org/lkml/aXuxVSbk1GR2ttzF@agluck-desk3/
Let me know if there are other ways to optimize this.
Patch 1: Data structures and arch hook: Add resctrl_kmode,
resctrl_kmode_cfg, kernel-mode bits, and resctrl_arch_get_kmode_cfg()
for generic resctrl kernel mode (e.g. PLZA).
Patch 2: Implement resctrl_arch_get_kmode_cfg() on x86, add global resctrl_kcfg
and resctrl_kmode_init() to set default kmode.
Patch 3: Add info/kernel_mode and resctrl_kernel_mode_show() to list supported
kernel modes and show the current one in brackets.
Patch 4: Add x86 PLZA support and boot option rdt=plza.
Patch 5: Add supported modes from CPUID.
Patch 6: Add rdt_kmode_enable_key and arch enable/disable helpers so PLZA only
touches fast paths when enabled.
Patch 7: Add MSR_IA32_PQR_PLZA_ASSOC, bit defines, and union qos_pqr_plza_assoc
for programming PLZA.
Patch 8: Add Per-CPU and per-task state.
Patch 9: Add resctrl_arch_configure_kmode() and resctrl_arch_set_kmode()
to program PLZA per domain and set/clear it on a CPU.
Patch 10: In the sched-in path, program MSR_IA32_PQR_PLZA_ASSOC from task or
per-CPU kmode; only write when kmode changes; guard with rdt_kmode_enable_key.
Patch 11: Add write handler so the current kernel mode can be set by name.
Patch 12: Add info/kernel_mode_assignment and show which rdtgroup is assigned
for kernel mode in CTRL_MON/MON/ form.
Patch 13: Add write handler to assign/clear the group used for kernel mode;
enforce single assignment and clear on rmdir.
Patch 14: Update per-CPU PLZA state when its cpu_mask changes (add/remove CPUs)
via cpus_write_kmode() and helpers.
Patch 15: Refactor so task list respects t->kmode when the group has kmode (PLZA),
so tasks are shown correctly.
v2: https://lore.kernel.org/lkml/cover.1773347820.git.babu.moger@amd.com/
v1: https://lore.kernel.org/lkml/cover.1769029977.git.babu.moger@amd.com/
Babu Moger (12):
x86/resctrl: Support Privilege-Level Zero Association (PLZA)
x86/resctrl: Add data structures and definitions for PLZA configuration
fs/resctrl: Add kernel mode (kmode) data structures and arch hook
x86,fs/resctrl: Program PLZA through kmode arch hooks
x86/resctrl: Initialize supported kernel modes for PLZA
fs/resctrl: Initialize the global kernel-mode policy at subsystem init
fs/resctrl: Add info/kernel_mode for kernel-mode policy introspection
fs/resctrl: Make info/kernel_mode writable and identify the bound group
fs/resctrl: Reset kernel-mode binding when its rdtgroup goes away
fs/resctrl: Expose kmode_cpus / kmode_cpus_list per rdtgroup
resctrl: Hide kmode_cpus[_list] on groups not bound to kernel-mode
fs/resctrl: Allow user space to write kmode_cpus / kmode_cpus_list
Documentation/filesystems/resctrl.rst | ...
arch/x86/kernel/cpu/resctrl/... | ...
fs/resctrl/... | ...
include/linux/resctrl.h | ...
include/linux/resctrl_types.h | ...
N files changed, X insertions(+), Y deletions(-)
--
2.43.0
Babu Moger (12):
x86/resctrl: Support Privilege-Level Zero Association (PLZA)
x86/resctrl: Add data structures and definitions for PLZA
configuration
fs/resctrl: Add kernel mode (kmode) data structures and arch hook
x86,fs/resctrl: Program PLZA through kmode arch hooks
x86/resctrl: Initialize supported kernel modes for PLZA
fs/resctrl: Initialize the global kernel-mode policy at subsystem init
fs/resctrl: Add info/kernel_mode for kernel-mode policy introspection
fs/resctrl: Make info/kernel_mode writable and identify the bound
group
fs/resctrl: Reset kernel-mode binding when its rdtgroup goes away
fs/resctrl: Expose kmode_cpus / kmode_cpus_list per rdtgroup
resctrl: Hide kmode_cpus[_list] on groups not bound to kernel-mode
fs/resctrl: Allow user space to write kmode_cpus / kmode_cpus_list
.../admin-guide/kernel-parameters.txt | 2 +-
Documentation/filesystems/resctrl.rst | 84 ++
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 7 +
arch/x86/kernel/cpu/resctrl/core.c | 17 +
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 35 +
arch/x86/kernel/cpu/resctrl/internal.h | 27 +
arch/x86/kernel/cpu/scattered.c | 1 +
fs/resctrl/internal.h | 6 +
fs/resctrl/rdtgroup.c | 784 ++++++++++++++++++
include/linux/resctrl.h | 23 +
include/linux/resctrl_types.h | 46 +
12 files changed, 1032 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 0/5] docs: watchdog: general cleaning and corrections
From: Guenter Roeck @ 2026-04-30 23:21 UTC (permalink / raw)
To: Randy Dunlap, Jonathan Corbet, linux-kernel
Cc: Shuah Khan, Wim Van Sebroeck, linux-watchdog, linux-doc
In-Reply-To: <8161ef45-be1a-41e2-a22b-a12d6b9df666@infradead.org>
On 4/30/26 15:14, Randy Dunlap wrote:
> Hi Wim,
>
> On 3/22/26 5:54 PM, Randy Dunlap wrote:
>>
>>
>> On 3/3/26 9:23 AM, Jonathan Corbet wrote:
>>> Randy Dunlap <rdunlap@infradead.org> writes:
>>>
>>>> Fix some obvious issues in the watchdog documentation files.
>>>> I didn't try to fix every little niggling mistake.
>>>>
>>>> [PATCH 1/5] docs: watchdog: mlx-wdt: small fixes
>>>> [PATCH 2/5] docs: watchdog: pcwd: fix typo and driver info.
>>>> [PATCH 3/5] docs: watchdog-api: general cleaning
>>>> [PATCH 4/5] docs: watchdog-kernel-api: general cleanups
>>>> [PATCH 5/5] docs: watchdog-parameters: add missing watchdog_core parameters
>>>>
>>>> Documentation/watchdog/mlx-wdt.rst | 4 -
>>>> Documentation/watchdog/pcwd-watchdog.rst | 19 +++++--
>>>> Documentation/watchdog/watchdog-api.rst | 38 +++++++--------
>>>> Documentation/watchdog/watchdog-kernel-api.rst | 20 +++++--
>>>> Documentation/watchdog/watchdog-parameters.rst | 11 +++-
>>>> 5 files changed, 58 insertions(+), 34 deletions(-)
>>>
>>> Wim, do you want to pick these up, or should I take them through the
>>> docs tree?
>>
>> Wim, are you active? Can you reply and/or merge these?
>
> What's happening with these 5 patches?
>
It looks like Wim did not send a pull request for watchdog this time around/
Wim, are you still active, or should I send pull requests going forward ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 0/8] x86/resctrl: Support for AMD Global (Slow) Memory Bandwidth Allocation
From: Moger, Babu @ 2026-04-30 23:04 UTC (permalink / raw)
To: Reinette Chatre, Babu Moger, corbet, tony.luck, tglx, mingo, bp,
dave.hansen
Cc: skhan, x86, Dave.Martin, james.morse, hpa, akpm, rdunlap,
dapeng1.mi, kees, elver, lirongqing, ebiggers, paulmck, seanjc,
pawan.kumar.gupta, nikunj, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, thomas.lendacky, naveen, elena.reshetova, xin,
linux-doc, linux-kernel, eranian, peternewman
In-Reply-To: <cb8272dc-4419-45a9-8cb4-110c803e62ee@intel.com>
Hi Reinette,
On 4/29/2026 5:34 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 4/23/26 6:41 PM, Babu Moger wrote:
>>
>> This series adds resctrl support for two new AMD memory-bandwidth
>> allocation features:
>>
>> - GMBA - Global Memory Bandwidth Allocation (hardware name: GLBE).
>> Bounds DRAM bandwidth for groups of threads that span
>> multiple L3 QoS domains, rather than being per-L3 like MBA.
>>
>> - GSMBA - Global Slow Memory Bandwidth Allocation (hardware name:
>> GLSBE). The CXL.memory / slow-memory counterpart of GMBA,
>> analogous to how SMBA relates to MBA.
>>
>> Both features share a new "NPS-node" control domain: a set of QoS (L3)
>> domains grouped together and aligned to the system's NPS (Nodes Per
>> Socket) BIOS configuration. Although the control domain is NPS-scoped,
>> the underlying bandwidth-limit MSRs (MSR_IA32_GMBA_BW_BASE 0xc0000600,
>> MSR_IA32_GSMBA_BW_BASE 0xc0000680) are instantiated per L3. Programming
>> a single control domain therefore requires writing the MSR on one CPU
>> per L3 that the domain spans - a new pattern for resctrl. Patches 2/8
>> and 3/8 introduce that infrastructure so the new resources can reuse
>> it.
>>
>> The features are documented in:
>>
>> AMD64 Zen6 Platform Quality of Service (PQOS) Extensions,
>> Publication # 69193 Revision 1.00, Issue Date March 2026
>>
>> available at https://bugzilla.kernel.org/show_bug.cgi?id=206537
>>
>> Series overview
>> ---------------
>>
>> Patches 1-5 to enable GMBA:
>>
>> 1/8 x86,fs/resctrl: Add support for Global Bandwidth Enforcement (GLBE)
>>
>> 2/8 x86/resctrl: Add RESCTRL_NPS_NODE scope for AMD NPS-aligned domains
>> Add a new ctrl_scope value for resctrl resources whose control
>> domain spans multiple L3s within an NPS node.
>>
>> 3/8 x86/resctrl: Update control MSRs per L3 for NPS-scoped resources
>> Add resctrl_arch_update_nps(): builds a cpumask with one CPU per
>> distinct L3 in the domain, then issues rdt_ctrl_update() via
>> smp_call_function_many() on that mask. Falls back to the full
>> domain mask if the scratch masks cannot be built. Route
>> resctrl_arch_update_domains() and resctrl_arch_reset_all_ctrls()
>> through this helper when ctrl_scope == RESCTRL_NPS_NODE.
>>
>> 4/8 x86,fs/resctrl: Add the resource for Global Memory Bandwidth Allocation
>> Register RDT_RESOURCE_GMBA in rdt_resources_all[] with
>> ctrl_scope=RESCTRL_NPS_NODE and schema_fmt=RANGE, add commands to
>> discover feature details.
>>
>> 5/8 fs/resctrl: Add the documentation for Global Memory Bandwidth Allocation
>> Add examples in Documentation/filesystems/resctrl.rst.
>>
>> Patches 6-8 to enable GSMBA in the same shape:
>>
>> 6/8 x86,fs/resctrl: Add support for Global Slow Memory Bandwidth Allocation
>>
>> 7/8 x86,fs/resctrl: Add the resource for Global Slow Memory Bandwidth Allocation
>> Register RDT_RESOURCE_GSMBA with ctrl_scope=RESCTRL_NPS_NODE.
>>
>> 8/8 fs/resctrl: Add the documentation for Global Slow Memory Bandwidth Allocation
>> Add examples in Documentation/filesystems/resctrl.rst.
>>
>> Changes since v1
>> ----------------
>> - Earlier sent RFC(v1) with Global Bandwidth Enforcement (GLBE) and
>> Privilege Level Zero Association (PLZA). This series only handles
>> Global Memory Bandwidth Allocation. Both the features are sent separately.
>>
>> - Documentation
>> * Fixed grammar in the GMBA / GSMBA sections of resctrl.rst.
>> * Added examples to update GMBA and GSMBA in resctrl.rst documentation.
>>
>> - Major changes are releated to RESCTRL_NPS_NODE scope handling.
>>
>> - Commit messages
>> * Reworked the changelogs in all the patches.
>>
>> Previous Revisions:
>> v1 : https://lore.kernel.org/lkml/cover.1769029977.git.babu.moger@amd.com/
>
> What are your expectations from this submission? From what I can tell this ignores
> v1 feedback in several ways:
> - It introduces two new resources, GMBA and GSMBA, when the previous discussion agreed that
> these are not actually new resources but instead new controls for the existing MBA/SMBA resources.
> - It does not mention or attempt to address dependency on new resource schema descriptions [1]
> to support user space in understanding how to interact with the new GMBA/GSMBA controls but
> instead defers that to a snippet in the documentation that user space needs to
> parse to know this control operates at multiples of 1GB/s.
>
> Apart from ignoring v1 feedback this new version appears to complicate user interface even more
> since now it is possible for there to be a single control that may operate at different scopes but from
> what I can tell there is nothing that helps user understand whether, for example, domain "0" means
> the whole system or a NUMA node?
>
> We have discussed several times now how resctrl interface needs to be enhanced to support
> this and other upcoming features from Intel, RISC-V, Arm MPAM, and NVidia. It is thus
> unexpected that this submission ignores all the previous discussions.
I think there may be some misunderstanding on this topic.
Yes, we discussed it earlier. It depends on other requirements
(region-aware aspects), so I assumed it would be handled by someone with
full context and addressed as a separate feature. I didn’t have complete
visibility into all the requirements.
>
> Since there are so many dependencies on the new schema format support I am prioritizing this
> and created a PoC that I am currently refining and hope to share soon. We can collaborate on this
> to ensure that it provides a good foundation for the GMBA and GSMBA support.
That is good to know. Let me know when you are ready.
Could you please share which parts of the feature (e.g., Part 1, Part 2,
etc.) you are planning to cover in your PoC?
>
> Consider what I describe in [2] - even in that response I speculate that a "scope" may be needed and
> this seems to be case. I believe would help this "NPS = 4" scenario. Adding "scope" to what I shared in
> [2] may look like:
>
> info/
> └── MB/
> └── resource_schemata/
> ├── GMB/
> │ ├── max:4096
> │ ├── min:1
> │ ├── resolution:1
> │ ├── scale:1
> │ ├── tolerance:0
> │ ├── type:scalar linear
> │ ├── scope:NODE
> │ └── unit:GBps
> └── MB/
> ├── max:8192
> ├── min:1
> ├── resolution:8
> ├── scale:1
> ├── tolerance:0
> ├── type:scalar linear
> ├── scope:L3
> └── unit:GBps
>
> With a "scope" property of the control user space can know what the domain ID in the
> schemata file refers to. In above example the "GMB" control has "NODE" scope so user space knows
> that a domain ID refers to NUMA node. If the system is "NPS = 4" then the scope could be,
> for example, "SYSTEM" (for the lack of a better term) so that user space knows that "0" means
> entire system. What do you think?
Yes. Sound good to me.
>
> Also note how the other control properties helps user understand what the schemata file control
> values mean. This is what I expected the GMBA/GSMBA enabling to look like ... and you seemed to
> agree [3] in v1 discussion. What changed?
Again, I was under the impression that this would be handled as a
separate feature and patch series.
Thanks
Babu
^ permalink raw reply
* [PATCH] hwmon: (yogafan) fix non-kernel-doc header warning
From: Sergio Melas @ 2026-04-30 22:40 UTC (permalink / raw)
To: lkp; +Cc: linux-doc, linux-kernel, linux, llvm, oe-kbuild-all, sergiomelas
In-Reply-To: <202604301429.UUK5MS9i-lkp@intel.com>
hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring.
This driver provides fan speed monitoring for Lenovo Yoga, Legion, and
IdeaPad laptops by interfacing with the Embedded Controller (EC) via ACPI.
The current header comment starts with '/**', which is reserved for
kernel-doc, this triggers a warning so we update it starting to '/*'
to avoid the compile warning.
Fixes: c67c248ca406 ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604301429.UUK5MS9i-lkp@intel.com/
Signed-off-by: Sergio Melas <sergiomelas@gmail.com>
---
v11.1:
- Fix comment header to resolve 0-day robot warning.
v11:
- Mapped ACPI paths directly via DMI quirks.
- Fixed Documentation formatting (0-day robot warnings).
- Implemented 100ms MIN_SAMPLING to address rapid polling concerns.
- Removed redundant platform_set_drvdata() in probe.
- Explicitly defined platform device ID as -1 for cleaner sysfs naming.
v9/10:
- Implement ACPI handle resolution during probe for better performance (O(1) read).
- Add MODULE_DEVICE_TABLE(dmi, ...) to enable module autoloading.
- Refine RLLag filter documentation and suspend/resume logic.
- Include comprehensive EC architecture research database (8-bit vs 16-bit).
- Validated efficiency on kernels 6.18, 6.19, and 7.0-rc5: 'perf top'
confirms negligible CPU overhead (<0.01%) during active polling.
v8:
- Replaced heuristic multiplier with deterministic DMI Quirk Table.
- Added 'depends on DMI' to Kconfig.
- Verified FOPTD model (1000ms TAU / 1500 RPM/s slew) against hardware traces.
- Increased filter precision to 12-bit fixed-point.
v7:
- Fixed Kconfig: Removed non-existent 'select MATH64'.
- Fixed unused macro: Utilized RPM_FLOOR_LIMIT to implement an
immediate 0-RPM bypass in the filter.
- Clarification: Previous "unified structure" comment meant that all
6 files (driver, docs, metadata) are now in this single atomic patch.
v6:
- Unified patch structure (6 files changed).
- Verified FOPTD (First-Order Plus Time Delay) model against hardware
traces (Yoga 14c) to ensure physical accuracy of the 1000ms time constant.
- Fixed a rounding stall: added a +/- 1 RPM floor to the step calculation
to ensure convergence even at high polling frequencies.
- Set MAX_SLEW_RPM_S to 1500 to match physical motor inertia.
- Documentation: Updated to clarify 100-RPM hardware step resolution.
- 32-bit safety: Implemented div64_s64 for coefficient precision.
v5:
- Fixed 32-bit build failures by using div64_s64 for 64-bit division.
- Extracted magic numbers into constants (RPM_UNIT_THRESHOLD, etc.).
- Fixed filter stall by ensuring a minimum slew limit (limit = 1).
- Refined RPM floor logic to trigger only when hardware reports 0 RPM.
- Resolved 255/256 unit-jump bug by adjusting heuristic thresholds.
v4:
- Rebased on groeck/hwmon-next branch for clean application.
- Corrected alphabetical sorting in Kconfig and Makefile.
- Technical Validation & FOPTD Verification:
- Implemented RLLag (Rate-Limited Lag) first-order modeling.
- Used 10-bit fixed-point math for alpha calculation to avoid
floating point overhead in the kernel.
- Added 5000ms filter reset for resume/long-polling sanitation.
v3:
- Added MAINTAINERS entry and full Documentation/hwmon/yogafan.rst.
- Fixed integer overflow in filter math.
- Added support for secondary fan paths (FA2S) for Legion laptops.
v2:
- Migrated from background worker to passive multirate filtering.
- Implemented dt-based scaling to maximize CPU sleep states.
- Restricted driver to Lenovo hardware via DMI matching.
v1:
- Initial submission with basic ACPI fan path support.
---
drivers/hwmon/yogafan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/yogafan.c b/drivers/hwmon/yogafan.c
index 605cc928f..314ee6195 100644
--- a/drivers/hwmon/yogafan.c
+++ b/drivers/hwmon/yogafan.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* yoga_fan.c - Lenovo Yoga/Legion Fan Hardware Monitoring Driver
*
* Provides fan speed monitoring for Lenovo Yoga, Legion, and IdeaPad
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/5] docs: watchdog: general cleaning and corrections
From: Randy Dunlap @ 2026-04-30 22:14 UTC (permalink / raw)
To: Jonathan Corbet, linux-kernel
Cc: Shuah Khan, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
linux-doc
In-Reply-To: <3de4c724-39bf-47f9-bf43-49552bc60a3a@infradead.org>
Hi Wim,
On 3/22/26 5:54 PM, Randy Dunlap wrote:
>
>
> On 3/3/26 9:23 AM, Jonathan Corbet wrote:
>> Randy Dunlap <rdunlap@infradead.org> writes:
>>
>>> Fix some obvious issues in the watchdog documentation files.
>>> I didn't try to fix every little niggling mistake.
>>>
>>> [PATCH 1/5] docs: watchdog: mlx-wdt: small fixes
>>> [PATCH 2/5] docs: watchdog: pcwd: fix typo and driver info.
>>> [PATCH 3/5] docs: watchdog-api: general cleaning
>>> [PATCH 4/5] docs: watchdog-kernel-api: general cleanups
>>> [PATCH 5/5] docs: watchdog-parameters: add missing watchdog_core parameters
>>>
>>> Documentation/watchdog/mlx-wdt.rst | 4 -
>>> Documentation/watchdog/pcwd-watchdog.rst | 19 +++++--
>>> Documentation/watchdog/watchdog-api.rst | 38 +++++++--------
>>> Documentation/watchdog/watchdog-kernel-api.rst | 20 +++++--
>>> Documentation/watchdog/watchdog-parameters.rst | 11 +++-
>>> 5 files changed, 58 insertions(+), 34 deletions(-)
>>
>> Wim, do you want to pick these up, or should I take them through the
>> docs tree?
>
> Wim, are you active? Can you reply and/or merge these?
What's happening with these 5 patches?
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: David Matlack @ 2026-04-30 21:22 UTC (permalink / raw)
To: Vipin Sharma
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <20260430204009.GB22297.vipinsh@google.com>
On Thu, Apr 30, 2026 at 1:42 PM Vipin Sharma <vipinsh@google.com> wrote:
>
> On Thu, Apr 30, 2026 at 08:36:36PM +0000, David Matlack wrote:
> > On 2026-04-30 11:25 AM, Vipin Sharma wrote:
> > > On Tue, Apr 28, 2026 at 02:12:13PM -0700, David Matlack wrote:
> > > > On Tue, Apr 28, 2026 at 1:20 PM Vipin Sharma <vipinsh@google.com> wrote:
> > > > >
> > > > > On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> > > > > > +int pci_liveupdate_preserve(struct pci_dev *dev)
> > > > > > +{
> >
> > > > > > + if (ser->nr_devices == ser->max_nr_devices)
> > > > > > + return -ENOSPC;
> > > > > > +
> > > > > > + for (i = 0; i < ser->max_nr_devices; i++) {
> > > > > > + /*
> > > > > > + * Start searching at index ser->nr_devices. This should result
> > > > > > + * in a constant time search under expected conditions (devices
> > > > > > + * are not getting unpreserved).
> > > > > > + */
> > > > > > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
> > > > > > + struct pci_dev_ser *dev_ser = &ser->devices[index];
> > > > > > +
> > > > > > + if (dev_ser->refcount)
> > > > > > + continue;
> > > > > > +
> > > > > > + pci_info(dev, "Device will be preserved across next Live Update\n");
> > > > > > + ser->nr_devices++;
> > > > > > +
> > > > > > + dev_ser->domain = pci_domain_nr(dev->bus);
> > > > > > + dev_ser->bdf = pci_dev_id(dev);
> > > > > > + dev_ser->refcount = 1;
> > > > > > +
> > > > > > + dev->liveupdate_outgoing = dev_ser;
> > > > > > + return 0;
> > > > > > + }
> > > > > > +
> > > > > > + return -ENOSPC;
> > > > >
> > > > > Since it is executing under a mutex, and we already failed
> > > > > 'if (ser->nr_devices == ser->max_nr_devices) check above, will we ever reach
> > > > > here and return -ENOSPC?
> > > >
> > > > Yeah I wouldn't expect to ever reach here.
> > >
> > > Will you be removing it or want to keep it just in case scenario?
> >
> > I'm not sure how I would remove it. The code doesn't not compile without
> > a return.
>
> Oh, I meant, inside loop a break and outside just return 0, that way it
> won't be a dead code.
That would hide bugs if the refcounts in the array got messed up. How about:
/* This should never be reached. */
return WARN_ON_ONCE(-ENOSPC);
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: David Matlack @ 2026-04-30 21:16 UTC (permalink / raw)
To: Samiullah Khawaja
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Shuah Khan, Will Deacon, William Tu, Yi Liu
In-Reply-To: <afDvVhkp8tQpsVlt@google.com>
On 2026-04-28 05:35 PM, Samiullah Khawaja wrote:
> On Tue, Apr 28, 2026 at 05:24:53PM +0000, Samiullah Khawaja wrote:
> > On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> > > Add APIs to allow drivers to notify the PCI core of which devices are
> > > being preserved across a Live Update for the next kernel, i.e.
> > > "outgoing" devices.
> > >
> > > Drivers must notify the PCI core when devices are preserved so that the
> > > PCI core can update its FLB data (struct pci_ser) and track the list of
> > > outgoing devices. pci_liveupdate_preserve() notifies the PCI core that a
> > > device must be preserved across Live Update. pci_liveupdate_unpreserve()
> > > reverses this (cancels the preservation of the device).
> > >
> > > This tracking ensures the PCI core is fully aware of which devices may
> > > need special handling during shutdown and kexec, and so that it can be
> > > handed off to the next kernel.
> > >
> > > Signed-off-by: David Matlack <dmatlack@google.com>
> > > ---
> > > drivers/pci/liveupdate.c | 101 ++++++++++++++++++++++++++++++++++++
> > > include/linux/kho/abi/pci.h | 7 +--
> > > include/linux/pci.h | 26 ++++++++++
> > > 3 files changed, 131 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/include/linux/kho/abi/pci.h b/include/linux/kho/abi/pci.h
> > > index 5c0e92588c00..5b4c8d9e462c 100644
> > > --- a/include/linux/kho/abi/pci.h
> > > +++ b/include/linux/kho/abi/pci.h
> > > @@ -23,19 +23,20 @@
> > > * incrementing the version number in the PCI_LUO_FLB_COMPATIBLE string.
> > > */
> > >
> > > -#define PCI_LUO_FLB_COMPATIBLE "pci-v1"
> > > +#define PCI_LUO_FLB_COMPATIBLE "pci-v2"
> > >
> > > /**
> > > * struct pci_dev_ser - Serialized state about a single PCI device.
> > > *
> > > * @domain: The device's PCI domain number (segment).
> > > * @bdf: The device's PCI bus, device, and function number.
> > > - * @reserved: Reserved (to naturally align struct pci_dev_ser).
> > > + * @refcount: Reference count used by the PCI core to keep track of whether it
> > > + * is done using a device's struct pci_dev_ser.
>
> nit: I was wondering why is this named refcount and why it is needed. It
> seems you are using it to track the preservation dependency between
> parent devices and leaf. Maybe add a comment to clarify that.
Ack, I will clarify that more in the kerneldoc in v5, thanks.
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: David Matlack @ 2026-04-30 21:15 UTC (permalink / raw)
To: Samiullah Khawaja
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Shuah Khan, Will Deacon, William Tu, Yi Liu
In-Reply-To: <afDqs6oqWlhoVqMN@google.com>
On 2026-04-28 05:24 PM, Samiullah Khawaja wrote:
> On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> > + for (i = 0; i < ser->max_nr_devices; i++) {
> > + /*
> > + * Start searching at index ser->nr_devices. This should result
> > + * in a constant time search under expected conditions (devices
> > + * are not getting unpreserved).
> > + */
> > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
> > + struct pci_dev_ser *dev_ser = &ser->devices[index];
>
> nit: Maybe we can move this logic in a separate function as down the road
> when we expand this to add VFs and Hotpluggable devices, this might
> change significantly? It's good if it is self-contained.
Did you mean to leave this comment on pci_flb_preserve() where it
decides how many devices to allocate room for?
> > +static inline struct pci_dev_ser *pci_liveupdate_outgoing(struct pci_dev *dev)
> > +{
> > + return dev->liveupdate_outgoing;
> > +}
>
> Is this expected to be called under the outgoing lock?
For now this API is only used during shutdown, at which point userspace
should have already been stopped so drivers should not be changing the
preservation status of an outgoing device. So I don't think this needs
to be under the outgoing lock, but it would be nice to have some more
explicit synchronization.
^ permalink raw reply
* Re: [PATCH v4 01/11] PCI: liveupdate: Set up FLB handler for the PCI core
From: Bjorn Helgaas @ 2026-04-30 21:06 UTC (permalink / raw)
To: David Matlack
Cc: Pasha Tatashin, Pratyush Yadav, iommu, kexec, linux-doc,
linux-kernel, linux-mm, linux-pci, Adithya Jayachandran,
Alexander Graf, Alex Williamson, Bjorn Helgaas, Chris Li,
David Rientjes, Jacob Pan, Jason Gunthorpe, Joerg Roedel,
Jonathan Corbet, Josh Hilke, Leon Romanovsky, Lukas Wunner,
Mike Rapoport, Parav Pandit, Pranjal Shrivastava, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <afFHC6C1Qbwio4pH@google.com>
On Tue, Apr 28, 2026 at 11:47:23PM +0000, David Matlack wrote:
> On 2026-04-28 05:50 PM, Pasha Tatashin wrote:
> > On 04-27 23:59, David Matlack wrote:
> > > On 2026-04-24 01:29 PM, Pasha Tatashin wrote:
> > > > On 04-24 14:33, Pratyush Yadav wrote:
> > > > > On Thu, Apr 23 2026, David Matlack wrote:
> > > > > [...]
> > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > index c9b7b6f9828e..94af31837375 100644
> > > > > > --- a/MAINTAINERS
> > > > > > +++ b/MAINTAINERS
> > > > > > @@ -20555,6 +20555,18 @@ L: linux-pci@vger.kernel.org
> > > > > > S: Supported
> > > > > > F: Documentation/PCI/pci-error-recovery.rst
> > > > > >
> > > > > > +PCI LIVE UPDATE
> > > > > > +M: Bjorn Helgaas <bhelgaas@google.com>
> > > > > > +M: David Matlack <dmatlack@google.com>
> > > > > > +L: linux-pci@vger.kernel.org
> > > > > > +S: Supported
> > > > > > +Q: https://patchwork.kernel.org/project/linux-pci/list/
> > > > > > +B: https://bugzilla.kernel.org
> > > > > > +C: irc://irc.oftc.net/linux-pci
> > > > > > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > > > > +F: drivers/pci/liveupdate.c
> > > > > > +F: include/linux/kho/abi/pci.h
> > > > > > +
> > > > >
> > > > > Can we please also add these files under the "LIVE UPDATE" entry. The
> > > > > code here concerns both live update and PCI.
> > >
> > > Covering that intersection of Live Update and PCI was exactly my
> > > intention with introducing this new PCI LIVE UPDATE entry. This ensures
> > > we have maintenance coverage with knowledge of that intersection.
> > >
> > > > > We can figure out the
> > > > > maintenance details as we go along, but I think the live update
> > > > > maintainers should at least get all the patches for PCI live update.
> ...
> > This is the way we agreed to handle kexec changes: Baoquan He is the
> > maintainer, and without his Reviewed-by tag, we won't take changes to
> > kexec. This is the approach we follow with MM for KHO changes to
> > memblock and memfd preservation, as well as the upcoming
> > hugetlb/guestmemfd preservation.
> >
> > This is also the approach we should continue using when adding LUO
> > support to other components like PCI, VFIO, IOMMU, and KVM. It keeps
> > life easier for the core component maintainers and ensures we do not
> > regress LU by staging everything in the same tree and sending LU merge
> > requests from a single tree.
>
> Ok it sounds like we are aligned on keeping drivers/pci/liveupdate.c,
> include/linux/kho/abi/pci.h, and Documentation/PCI/liveupdate.rst in the
> PCI LIVE UPDATE entry and not duplicating them in the LIVE UPDATE entry.
>
> I think the only open question is what tree to use for the PCI LIVE
> UPDATE entry, PCI tree or Live Update tree. You are proposing the Live
> Update tree.
>
> Bjorn are you ok with that approach?
Yes, I think that makes sense, at least to start. In early days, it
would probably be a headache to coordinate LU things across multiple
trees.
^ permalink raw reply
* Re: [PATCH v4 08/11] PCI: liveupdate: Require preserved devices are in immutable singleton IOMMU groups
From: David Matlack @ 2026-04-30 20:49 UTC (permalink / raw)
To: Jacob Pan
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jason Gunthorpe,
Joerg Roedel, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pasha Tatashin,
Pranjal Shrivastava, Pratyush Yadav, Robin Murphy, Saeed Mahameed,
Samiullah Khawaja, Shuah Khan, Will Deacon, William Tu, Yi Liu
In-Reply-To: <20260427135625.0000413e@linux.microsoft.com>
On 2026-04-27 01:56 PM, Jacob Pan wrote:
> On Thu, 23 Apr 2026 21:23:12 +0000
> David Matlack <dmatlack@google.com> wrote:
> > +bool pci_device_group_immutable_singleton(struct pci_dev *dev)
> > +{
> > + struct iommu_group *group;
> > + struct group_device *d;
> > + struct pci_bus *bus;
> > + int nr_devices = 0;
> > +
> > + group = iommu_group_get(&dev->dev);
> > + if (!group)
> > + return false;
> This may not work for noiommu mode where we could have a null group.
> Maybe I can add special case later?
Yeah depending which series goes in first. But based on the other thread
I am going to drop this patch from v5.
^ permalink raw reply
* Re: [PATCH v4 08/11] PCI: liveupdate: Require preserved devices are in immutable singleton IOMMU groups
From: David Matlack @ 2026-04-30 20:46 UTC (permalink / raw)
To: Samiullah Khawaja
Cc: Jason Gunthorpe, iommu, kexec, linux-doc, linux-kernel, linux-mm,
linux-pci, Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan, Joerg Roedel,
Jonathan Corbet, Josh Hilke, Leon Romanovsky, Lukas Wunner,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Pranjal Shrivastava,
Pratyush Yadav, Robin Murphy, Saeed Mahameed, Shuah Khan,
Will Deacon, William Tu, Yi Liu
In-Reply-To: <aeqpJ7BeBtzoPIx4@google.com>
On 2026-04-23 11:27 PM, Samiullah Khawaja wrote:
> On Thu, Apr 23, 2026 at 04:09:01PM -0700, David Matlack wrote:
> > On Thu, Apr 23, 2026 at 3:53 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> > >
> > > On Thu, Apr 23, 2026 at 03:10:55PM -0700, David Matlack wrote:
> > > > On Thu, Apr 23, 2026 at 2:23 PM David Matlack <dmatlack@google.com> wrote:
> > > > >
> > > > > Restrict support for preserving PCI devices across Live Update to
> > > > > devices in immutable singleton IOMMU groups. A device's group is
> > > > > considered immutable if all bridges upstream from the device up to the
> > > > > root port have the required ACS features enabled.
> > > > >
> > > > > Since ACS flags are inherited across a Live Update for preserved devices
> > > > > and all the way up to the root port, the preserved device should be in a
> > > > > singleton IOMMU group after kexec in the new kernel.
> > > > >
> > > > > This change should still permit all the current use-cases for PCI device
> > > > > preservation across Live Update, since it is intended to be used in
> > > > > Cloud enviroments which should have the required ACS features enabled
> > > > > for virtualization purposes.
> > > > >
> > > > > If a device is part of a multi-device IOMMU group, preserving it will
> > > > > now fail with an error. This restriction may be lifted in the future if
> > > > > support for preserving multi-device groups is desired.
> > > > >
> > > > > Signed-off-by: David Matlack <dmatlack@google.com>
> > > >
> > > > Jason, do you think requiring singleton iommu groups is still
> > > > necessary/useful now that this series preserves ACS flags on preserved
> > > > devices and upstream bridges?
> > >
> > > I have forgotten why we introduced that? There are alot of funky
> > > things about iommu groups that might be important upon restoration..
> >
> > You had originally suggested it in this thread:
> >
> > https://lore.kernel.org/kvm/20260301192236.GQ5933@nvidia.com/
> >
> > > Like if you preserve one group member but not the other what do you ?
> >
> > Yeah I imagine there could be some tricky cases there...
> >
> > I wonder if PCI core is the right layer to enforce this. Maybe this
> > fits better into Sami's IOMMU core series since that is where all
> > those tricky cases will be (I imagine?).
>
> +1
>
> Also I think this should probably be checked by iommufd and invoked
> through vfio cdev. Basically when vfio cdev calls into iommufd to
> preserve IOMMU specific aspects of device (PASID table etc), iommufd can
> check this and return error.
Ok I will drop this patch from v5. The IOMMU core can check for it if it
makes life simpler, but I can't think of anything in the PCI core that
cares about this check.
^ permalink raw reply
* Re: [PATCH v4 01/11] PCI: liveupdate: Set up FLB handler for the PCI core
From: David Matlack @ 2026-04-30 20:44 UTC (permalink / raw)
To: Vipin Sharma
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <20260430182532.GB13902.vipinsh@google.com>
On 2026-04-30 11:48 AM, Vipin Sharma wrote:
> On Tue, Apr 28, 2026 at 11:51:37PM +0000, David Matlack wrote:
> > On 2026-04-28 12:45 PM, Vipin Sharma wrote:
> > > On Thu, Apr 23, 2026 at 09:23:05PM +0000, David Matlack wrote:
> > > > + pr_debug("Preserving struct pci_ser with room for %u devices\n",
> > > > + max_nr_devices);
> > > > +
> > > > + ser = kho_alloc_preserve(size);
> > > > + if (IS_ERR(ser))
> > > > + return PTR_ERR(ser);
> > >
> > > Should there be a similar pr_debug() in case of failure to denote that above
> > > "Preserving ..." message didn't finish, or, maybe just print one
> > > pr_debug() after the error check above?
> >
> > Hm... I guess there could always be more pr_debug()s but I don't want to
> > instrument every error path. I could move it to the success path but I
> > don't see how that makes it any better.
> >
>
> In current way, it is printing that it is preserving pci_ser, but there
> is no indication did it succeed or not in logs. If we are printing the
> logs then may be complete picture will be to know what is the action and its
> result.
>
> I think moving to success path or printing again based on the failure
> provides assurance of what happened. If this gets printed in happy
> path, then we will know it succeeded in preserving that struct on
> kho. Absence means it didn't.
>
> We can also remove pr_debug(), if this is of no value.
I think I'll just drop these. BPF can be used to trace this function and
what it returns when debugging issues.
>
> > >
> > > > +/**
> > > > + * struct pci_dev_ser - Serialized state about a single PCI device.
> > > > + *
> > > > + * @domain: The device's PCI domain number (segment).
> > > > + * @bdf: The device's PCI bus, device, and function number.
> > > > + * @reserved: Reserved (to naturally align struct pci_dev_ser).
> > > > + */
> > > > +struct pci_dev_ser {
> > > > + u32 domain;
> > > > + u16 bdf;
> > > > + u16 reserved;
> > >
> > > Should this be renamed to 'u8 __padding[2];' instead? This will allow to
> > > just change the array length based on the need (0, 1, 2, 3).
> >
> > Sorry I'm not following what you mean here. What is the reason to rename
> > this field and change it to an array?
> >
>
> Having a padding explicitly tells there is a requirement of being
> aligned. Reserved sounds more like don't use this u16.
It's documented above, but agree padding is a better name.
> If someone add more field down the line say u8, then to make struct size
> aligned they will need to add another u8, u16, u32, and name those
> fields padding or reserved. IMO, having a u8 array named padding makes
> it easier to just change array length as per the need.
This field does get replaced in the next patch. But I see your point
that if we need to pad by an amount other than u8, u16, or u32, then we
would need an array.
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: Vipin Sharma @ 2026-04-30 20:42 UTC (permalink / raw)
To: David Matlack
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <afO9VOckgyiiokw8@google.com>
On Thu, Apr 30, 2026 at 08:36:36PM +0000, David Matlack wrote:
> On 2026-04-30 11:25 AM, Vipin Sharma wrote:
> > On Tue, Apr 28, 2026 at 02:12:13PM -0700, David Matlack wrote:
> > > On Tue, Apr 28, 2026 at 1:20 PM Vipin Sharma <vipinsh@google.com> wrote:
> > > >
> > > > On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> > > > > +int pci_liveupdate_preserve(struct pci_dev *dev)
> > > > > +{
>
> > > > > + if (ser->nr_devices == ser->max_nr_devices)
> > > > > + return -ENOSPC;
> > > > > +
> > > > > + for (i = 0; i < ser->max_nr_devices; i++) {
> > > > > + /*
> > > > > + * Start searching at index ser->nr_devices. This should result
> > > > > + * in a constant time search under expected conditions (devices
> > > > > + * are not getting unpreserved).
> > > > > + */
> > > > > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
> > > > > + struct pci_dev_ser *dev_ser = &ser->devices[index];
> > > > > +
> > > > > + if (dev_ser->refcount)
> > > > > + continue;
> > > > > +
> > > > > + pci_info(dev, "Device will be preserved across next Live Update\n");
> > > > > + ser->nr_devices++;
> > > > > +
> > > > > + dev_ser->domain = pci_domain_nr(dev->bus);
> > > > > + dev_ser->bdf = pci_dev_id(dev);
> > > > > + dev_ser->refcount = 1;
> > > > > +
> > > > > + dev->liveupdate_outgoing = dev_ser;
> > > > > + return 0;
> > > > > + }
> > > > > +
> > > > > + return -ENOSPC;
> > > >
> > > > Since it is executing under a mutex, and we already failed
> > > > 'if (ser->nr_devices == ser->max_nr_devices) check above, will we ever reach
> > > > here and return -ENOSPC?
> > >
> > > Yeah I wouldn't expect to ever reach here.
> >
> > Will you be removing it or want to keep it just in case scenario?
>
> I'm not sure how I would remove it. The code doesn't not compile without
> a return.
Oh, I meant, inside loop a break and outside just return 0, that way it
won't be a dead code.
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: David Matlack @ 2026-04-30 20:36 UTC (permalink / raw)
To: Vipin Sharma
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <20260430175916.GA13902.vipinsh@google.com>
On 2026-04-30 11:25 AM, Vipin Sharma wrote:
> On Tue, Apr 28, 2026 at 02:12:13PM -0700, David Matlack wrote:
> > On Tue, Apr 28, 2026 at 1:20 PM Vipin Sharma <vipinsh@google.com> wrote:
> > >
> > > On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> > > > +int pci_liveupdate_preserve(struct pci_dev *dev)
> > > > +{
> > > > + if (ser->nr_devices == ser->max_nr_devices)
> > > > + return -ENOSPC;
> > > > +
> > > > + for (i = 0; i < ser->max_nr_devices; i++) {
> > > > + /*
> > > > + * Start searching at index ser->nr_devices. This should result
> > > > + * in a constant time search under expected conditions (devices
> > > > + * are not getting unpreserved).
> > > > + */
> > > > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
> > > > + struct pci_dev_ser *dev_ser = &ser->devices[index];
> > > > +
> > > > + if (dev_ser->refcount)
> > > > + continue;
> > > > +
> > > > + pci_info(dev, "Device will be preserved across next Live Update\n");
> > > > + ser->nr_devices++;
> > > > +
> > > > + dev_ser->domain = pci_domain_nr(dev->bus);
> > > > + dev_ser->bdf = pci_dev_id(dev);
> > > > + dev_ser->refcount = 1;
> > > > +
> > > > + dev->liveupdate_outgoing = dev_ser;
> > > > + return 0;
> > > > + }
> > > > +
> > > > + return -ENOSPC;
> > >
> > > Since it is executing under a mutex, and we already failed
> > > 'if (ser->nr_devices == ser->max_nr_devices) check above, will we ever reach
> > > here and return -ENOSPC?
> >
> > Yeah I wouldn't expect to ever reach here.
>
> Will you be removing it or want to keep it just in case scenario?
I'm not sure how I would remove it. The code doesn't not compile without
a return.
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation/hwmon: add Delta E50SN12051 documentation
From: Guenter Roeck @ 2026-04-30 20:18 UTC (permalink / raw)
To: u8813345, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Colin Huang
In-Reply-To: <20260430-add-e50sn12051-v3-2-f6d4e043ec7c@gmail.com>
On 4/29/26 23:16, Colin Huang via B4 Relay wrote:
> From: Colin Huang <u8813345@gmail.com>
>
> Document the hardware monitoring support for the Delta E50SN12051
> device.
>
> The documentation describes the supported sensors exposed via the
> hwmon subsystem, including voltage, current, and temperature measurements.
>
> Signed-off-by: Colin Huang <u8813345@gmail.com>
For my reference:
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Documentation/hwmon/e50sn12051.rst | 81 ++++++++++++++++++++++++++++++++++++++
> Documentation/hwmon/index.rst | 1 +
> 2 files changed, 82 insertions(+)
>
> diff --git a/Documentation/hwmon/e50sn12051.rst b/Documentation/hwmon/e50sn12051.rst
> new file mode 100644
> index 000000000000..cbbfa7895d82
> --- /dev/null
> +++ b/Documentation/hwmon/e50sn12051.rst
> @@ -0,0 +1,81 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +Kernel driver e50sn12051
> +========================
> +
> +Supported chips:
> +
> + * Delta E50SN12051
> +
> + Prefix: 'e50sn12051'
> +
> + Addresses scanned: -
> +
> + Datasheet:
> +
> + Provided by Delta upon request and NDA
> +
> +Description
> +-----------
> +
> +E50SN12051 is a 600W non-isolated 1/8th brick DC-DC power module.
> +
> +This driver supports the E50SN12051 PMBus compliant monitor device.
> +
> +The device provides measurements for:
> +
> +* Input voltage
> +* Output current
> +* Output voltage
> +* Temperature
> +
> +The driver is based on the PMBus core and exposes standard hwmon
> +sysfs attributes.
> +
> +Sysfs attributes
> +----------------
> +
> +======================= =======================================================
> +curr1_label "iout1"
> +curr1_crit Critical maximum current.
> + From IOUT_OC_FAULT_LIMIT register.
> +curr1_crit_alarm Current critical high alarm.
> + From IOUT_OC_FAULT status.
> +curr1_input Measured current.
> + From READ_IOUT register.
> +curr1_max Maximum current.
> + From IOUT_OC_WARN_LIMIT register.
> +curr1_max_alarm Current high alarm.
> + From IOUT_OC_WARN_LIMIT status.
> +
> +in1_label "vin"
> +in1_alarm Input voltage alarm.
> +in1_input Measured voltage.
> + From READ_VIN register.
> +
> +in2_label "vout1"
> +in2_crit Critical maximum voltage.
> + From VOUT_OV_FAULT_LIMIT register.
> +in2_crit_alarm Voltage critical high alarm.
> + From VOLTAGE_OV_FAULT status.
> +in2_input Measured voltage.
> + From READ_VOUT register.
> +in2_max Maximum voltage.
> + From VOUT_OV_WARN_LIMIT register.
> +in2_max_alarm Voltage high alarm.
> + From VOLTAGE_OV_WARNING status.
> +
> +temp1_crit Critical high temperature.
> + From OT_FAULT_LIMIT register.
> +temp1_crit_alarm Module temperature critical high alarm.
> + Set by comparing READ_TEMPERATURE_1 with OT_FAULT_LIMIT
> + if TEMP_OT_FAULT status is set.
> +temp1_input Measured module's hot spot temperature.
> + From READ_TEMPERATURE_1 register.
> +temp1_max Maximum temperature.
> + From OT_WARN_LIMIT register.
> +temp1_max_alarm Module temperature high alarm.
> + Set by comparing READ_TEMPERATURE_1 with OT_WARN_LIMIT if
> + TEMP_OT_WARNING status is set.
> +======================= =======================================================
> +
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 8b655e5d6b68..ba08655fc496 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -68,6 +68,7 @@ Hardware Monitoring Kernel Drivers
> drivetemp
> ds1621
> ds620
> + e50sn12051
> emc1403
> emc2103
> emc2305
>
^ permalink raw reply
* Re: [PATCH v3 3/3] hwmon: (pmbus) add support for Delta E50SN12051
From: Guenter Roeck @ 2026-04-30 20:17 UTC (permalink / raw)
To: u8813345, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Colin Huang
In-Reply-To: <20260430-add-e50sn12051-v3-3-f6d4e043ec7c@gmail.com>
On 4/29/26 23:16, Colin Huang via B4 Relay wrote:
> From: Colin Huang <u8813345@gmail.com>
>
> Add the pmbus driver for Delta E50SN12051 600W Non-isolated
> 1/8th Brick DCDC Power Modules.
>
> Signed-off-by: Colin Huang <u8813345@gmail.com>
For my reference:
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/hwmon/pmbus/Kconfig | 9 +++++++
> drivers/hwmon/pmbus/Makefile | 1 +
> drivers/hwmon/pmbus/e50sn12051.c | 52 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 62 insertions(+)
>
> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> index 8f4bff375ecb..4fbfcbc4a9c5 100644
> --- a/drivers/hwmon/pmbus/Kconfig
> +++ b/drivers/hwmon/pmbus/Kconfig
> @@ -161,6 +161,15 @@ config SENSORS_DPS920AB
> This driver can also be built as a module. If so, the module will
> be called dps920ab.
>
> +config SENSORS_E50SN12051
> + tristate "Delta E50SN12051 Power Modules"
> + help
> + If you say yes here you get hardware monitoring support for Delta
> + E50SN12051 Power Modules.
> +
> + This driver can also be built as a module. If so, the module will
> + be called e50sn12051.
> +
> config SENSORS_INA233
> tristate "Texas Instruments INA233 and compatibles"
> help
> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> index 7129b62bc00f..fc910bf34fe3 100644
> --- a/drivers/hwmon/pmbus/Makefile
> +++ b/drivers/hwmon/pmbus/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_SENSORS_FSP_3Y) += fsp-3y.o
> obj-$(CONFIG_SENSORS_HAC300S) += hac300s.o
> obj-$(CONFIG_SENSORS_IBM_CFFPS) += ibm-cffps.o
> obj-$(CONFIG_SENSORS_DPS920AB) += dps920ab.o
> +obj-$(CONFIG_SENSORS_E50SN12051) += e50sn12051.o
> obj-$(CONFIG_SENSORS_INA233) += ina233.o
> obj-$(CONFIG_SENSORS_INSPUR_IPSPS) += inspur-ipsps.o
> obj-$(CONFIG_SENSORS_IR35221) += ir35221.o
> diff --git a/drivers/hwmon/pmbus/e50sn12051.c b/drivers/hwmon/pmbus/e50sn12051.c
> new file mode 100644
> index 000000000000..efb4d62b2603
> --- /dev/null
> +++ b/drivers/hwmon/pmbus/e50sn12051.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Hardware monitoring driver for E50SN12051
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include "pmbus.h"
> +
> +static struct pmbus_driver_info e50sn12051_info = {
> + .pages = 1,
> + .format[PSC_VOLTAGE_IN] = linear,
> + .format[PSC_VOLTAGE_OUT] = linear,
> + .format[PSC_CURRENT_OUT] = linear,
> + .format[PSC_TEMPERATURE] = linear,
> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT |
> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
> +};
> +
> +static const struct i2c_device_id e50sn12051_id[] = { { "e50sn12051", 0 }, {} };
> +MODULE_DEVICE_TABLE(i2c, e50sn12051_id);
> +
> +static const struct of_device_id e50sn12051_of_match[] = {
> + { .compatible = "delta,e50sn12051" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, e50sn12051_of_match);
> +
> +static int e50sn12051_probe(struct i2c_client *client)
> +{
> + return pmbus_do_probe(client, &e50sn12051_info);
> +}
> +
> +static struct i2c_driver e50sn12051_driver = {
> + .driver = {
> + .name = "e50sn12051",
> + .of_match_table = e50sn12051_of_match,
> + },
> + .probe = e50sn12051_probe,
> +
> + .id_table = e50sn12051_id,
> +};
> +
> +module_i2c_driver(e50sn12051_driver);
> +
> +MODULE_AUTHOR("Kevin Chang <kevin.chang2@amd.com>");
> +MODULE_DESCRIPTION("PMBus driver for E50SN12051");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("PMBUS");
>
^ permalink raw reply
* [PATCH] docs: cgroup-v1: Update charge-commit section
From: T.J. Mercier @ 2026-04-30 20:11 UTC (permalink / raw)
To: tj, hannes, mkoutny, cgroups
Cc: corbet, skhan, linux-doc, linux-kernel, T.J. Mercier
Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.
Update the docs to match the code.
Signed-off-by: T.J. Mercier <tjmercier@google.com>
---
Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba..7c7cd457cf69 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears.
-3. charge-commit-cancel
+3. charge-commit
=======================
Memcg pages are charged in two steps:
- mem_cgroup_try_charge()
- - mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+ - commit_charge()
At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE.
At commit(), the page is associated with the memcg.
- At cancel(), simply usage -= PAGE_SIZE.
-
Under below explanation, we assume CONFIG_SWAP=y.
4. Anonymous
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [RFC] Interest in contributing to Linux Kernel documentation (French translation)
From: Dewey @ 2026-04-30 20:10 UTC (permalink / raw)
To: linux-doc
Hello everyone,
My name is Dewey, I am a software enthusiast with an interest in the
Linux kernel. I am reaching out to the list to see if there is any
interest or an established process for improving the documentation by
adding or maintaining translations, specifically for French.
I understand that the official documentation is maintained in English
and that keeping translations in sync is a significant challenge.
However, I would like to offer my time to help, whether it involves
translating specific sections or helping with the automation of
documentation generation.
Could you let me know if there are any current initiatives regarding
translations, or if there is a preferred way to contribute in this
area?
Thank you for your time and guidance.
Best regards,
Dewey
^ permalink raw reply
* Re: [PATCH] Documentation: riscv: cmodx: fix typos
From: Paul Walmsley @ 2026-04-30 20:08 UTC (permalink / raw)
To: Avi Radinsky
Cc: palmer, pjw, aou, alex, corbet, linux-riscv, linux-doc,
linux-kernel
In-Reply-To: <391d16fb-5f11-45fa-8f3b-1debe095695e@tennr.com>
On Wed, 29 Apr 2026, Avi Radinsky wrote:
> Fix typos in the dynamic ftrace section: atmoic -> atomic (twice),
> pacthable -> patchable, derect -> directed.
>
> Signed-off-by: Avi Radinsky <avi.radinsky@tennr.com>
Thanks, queued for v7.1-rc.
- Paul
^ permalink raw reply
* Re: [PATCH v2] cgroup/cpuset: Clarify the delegation rules of partition
From: Waiman Long @ 2026-04-30 19:54 UTC (permalink / raw)
To: Michal Koutný
Cc: Chen Ridong, Tejun Heo, Johannes Weiner, Jonathan Corbet,
Shuah Khan, cgroups, linux-doc, linux-kernel, Xie Maoyi
In-Reply-To: <h46vz32432zl6xu773hfvnpze5zt7berywvg233esmeiftiruo@aub2kgpwi6zd>
On 4/30/26 3:46 PM, Michal Koutný wrote:
> On Tue, Apr 28, 2026 at 02:09:35PM -0400, Waiman Long <longman@redhat.com> wrote:
>> Creation of remote partition is currently not allowed without privilege.
>> On the other hand, creation of local partition is allowed without
>> privilege as long as its parent is also a partition root.
>>
>> The current setup allows a delegator to delegate an exclusive set of
>> CPUs to the delegatee by making the root of a delegated sub-hierarchy
>> a partition root. The delegatee is then allowed to create a local
>> sub-partition underneath it if necessary. Creation of a remote
>> partition is not currently allowed across delegation boundary without
>> privilege. Clarify the partition delegation rules by stating the current
>> behavior in cgroup-v2.rst file.
>>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> Documentation/admin-guide/cgroup-v2.rst | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
> After Tejun pointed out that other generic paragraph:
> | This means that the controller interface files - anything which
> | doesn't start with "cgroup." are owned by the parent rather than the
> | cgroup itself.
>
> I think the extra words may only increase confusion (and constrain
> generic changes). So it was a good exercise but nothing needs to be
> necessarily changed regarding this behaivor or its docs.
That is fine. This doc change is optional and I agree that we may want
more flexibility in case we change the behavior in the future.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH v2] cgroup/cpuset: Clarify the delegation rules of partition
From: Michal Koutný @ 2026-04-30 19:46 UTC (permalink / raw)
To: Waiman Long
Cc: Chen Ridong, Tejun Heo, Johannes Weiner, Jonathan Corbet,
Shuah Khan, cgroups, linux-doc, linux-kernel, Xie Maoyi
In-Reply-To: <20260428180935.806284-1-longman@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
On Tue, Apr 28, 2026 at 02:09:35PM -0400, Waiman Long <longman@redhat.com> wrote:
> Creation of remote partition is currently not allowed without privilege.
> On the other hand, creation of local partition is allowed without
> privilege as long as its parent is also a partition root.
>
> The current setup allows a delegator to delegate an exclusive set of
> CPUs to the delegatee by making the root of a delegated sub-hierarchy
> a partition root. The delegatee is then allowed to create a local
> sub-partition underneath it if necessary. Creation of a remote
> partition is not currently allowed across delegation boundary without
> privilege. Clarify the partition delegation rules by stating the current
> behavior in cgroup-v2.rst file.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> Documentation/admin-guide/cgroup-v2.rst | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
After Tejun pointed out that other generic paragraph:
| This means that the controller interface files - anything which
| doesn't start with "cgroup." are owned by the parent rather than the
| cgroup itself.
I think the extra words may only increase confusion (and constrain
generic changes). So it was a good exercise but nothing needs to be
necessarily changed regarding this behaivor or its docs.
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/11] PCI: liveupdate: Set up FLB handler for the PCI core
From: Vipin Sharma @ 2026-04-30 18:48 UTC (permalink / raw)
To: David Matlack
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <afFICT9mSL1XG0v_@google.com>
On Tue, Apr 28, 2026 at 11:51:37PM +0000, David Matlack wrote:
> On 2026-04-28 12:45 PM, Vipin Sharma wrote:
> > On Thu, Apr 23, 2026 at 09:23:05PM +0000, David Matlack wrote:
> > > + pr_debug("Preserving struct pci_ser with room for %u devices\n",
> > > + max_nr_devices);
> > > +
> > > + ser = kho_alloc_preserve(size);
> > > + if (IS_ERR(ser))
> > > + return PTR_ERR(ser);
> >
> > Should there be a similar pr_debug() in case of failure to denote that above
> > "Preserving ..." message didn't finish, or, maybe just print one
> > pr_debug() after the error check above?
>
> Hm... I guess there could always be more pr_debug()s but I don't want to
> instrument every error path. I could move it to the success path but I
> don't see how that makes it any better.
>
In current way, it is printing that it is preserving pci_ser, but there
is no indication did it succeed or not in logs. If we are printing the
logs then may be complete picture will be to know what is the action and its
result.
I think moving to success path or printing again based on the failure
provides assurance of what happened. If this gets printed in happy
path, then we will know it succeeded in preserving that struct on
kho. Absence means it didn't.
We can also remove pr_debug(), if this is of no value.
> >
> > > +/**
> > > + * struct pci_dev_ser - Serialized state about a single PCI device.
> > > + *
> > > + * @domain: The device's PCI domain number (segment).
> > > + * @bdf: The device's PCI bus, device, and function number.
> > > + * @reserved: Reserved (to naturally align struct pci_dev_ser).
> > > + */
> > > +struct pci_dev_ser {
> > > + u32 domain;
> > > + u16 bdf;
> > > + u16 reserved;
> >
> > Should this be renamed to 'u8 __padding[2];' instead? This will allow to
> > just change the array length based on the need (0, 1, 2, 3).
>
> Sorry I'm not following what you mean here. What is the reason to rename
> this field and change it to an array?
>
Having a padding explicitly tells there is a requirement of being
aligned. Reserved sounds more like don't use this u16.
If someone add more field down the line say u8, then to make struct size
aligned they will need to add another u8, u16, u32, and name those
fields padding or reserved. IMO, having a u8 array named padding makes
it easier to just change array length as per the need.
> > > +} __packed;
> > > +
> > > +/**
> > > + * struct pci_ser - PCI Subsystem Live Update State
> > > + *
> > > + * This struct tracks state about all devices that are being preserved across
> > > + * a Live Update for the next kernel.
> > > + *
> > > + * @max_nr_devices: The length of the devices[] flexible array.
> > > + * @nr_devices: The number of devices that were preserved.
> > > + * @devices: Flexible array of pci_dev_ser structs for each device.
> > > + */
> > > +struct pci_ser {
> > > + u32 max_nr_devices;
> > > + u32 nr_devices;
> > > + struct pci_dev_ser devices[];
> > > +} __packed;
> > > +
> > > +/* Ensure all elements of devices[] are naturally aligned. */
> > > +static_assert(offsetof(struct pci_ser, devices) % sizeof(unsigned long) == 0);
> > > +static_assert(sizeof(struct pci_dev_ser) % sizeof(unsigned long) == 0);
> >
> > Nit: Maybe move this assert to be near to the definition of this struct,
> > easier to find it when editing the struct vs finding it later during
> > build.
>
> The combination of these 2 asserts is what guarantees that every element
> of the devices[] array are naturally aligned, that's why I put them
> together here.
>
> I can move it up though if you think it's better.
Okay, SGTM.
^ permalink raw reply
* Re: [PATCH v4 02/11] PCI: liveupdate: Track outgoing preserved PCI devices
From: Vipin Sharma @ 2026-04-30 18:25 UTC (permalink / raw)
To: David Matlack
Cc: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <CALzav=dfLtdrPhkBkGwHpDAWUBMHnbGPccwhy1__doziNVZQJQ@mail.gmail.com>
On Tue, Apr 28, 2026 at 02:12:13PM -0700, David Matlack wrote:
> On Tue, Apr 28, 2026 at 1:20 PM Vipin Sharma <vipinsh@google.com> wrote:
> >
> > On Thu, Apr 23, 2026 at 09:23:06PM +0000, David Matlack wrote:
> > > +int pci_liveupdate_preserve(struct pci_dev *dev)
> > > +{
> > > + struct pci_ser *ser;
> > > + int i, ret;
> > > +
> > > + guard(mutex)(&pci_flb_outgoing_lock);
> > > +
> > > + ret = liveupdate_flb_get_outgoing(&pci_liveupdate_flb, (void **)&ser);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (!ser)
> > > + return -ENOENT;
> > > +
> > > + if (dev->is_virtfn)
> > > + return -EINVAL;
> > > +
> > > + if (dev->liveupdate_outgoing)
> > > + return -EBUSY;
> > > +
> > > + if (ser->nr_devices == ser->max_nr_devices)
> > > + return -ENOSPC;
> > > +
> > > + for (i = 0; i < ser->max_nr_devices; i++) {
> > > + /*
> > > + * Start searching at index ser->nr_devices. This should result
> > > + * in a constant time search under expected conditions (devices
> > > + * are not getting unpreserved).
> > > + */
> > > + int index = (ser->nr_devices + i) % ser->max_nr_devices;
> > > + struct pci_dev_ser *dev_ser = &ser->devices[index];
> > > +
> > > + if (dev_ser->refcount)
> > > + continue;
> > > +
> > > + pci_info(dev, "Device will be preserved across next Live Update\n");
> > > + ser->nr_devices++;
> > > +
> > > + dev_ser->domain = pci_domain_nr(dev->bus);
> > > + dev_ser->bdf = pci_dev_id(dev);
> > > + dev_ser->refcount = 1;
> > > +
> > > + dev->liveupdate_outgoing = dev_ser;
> > > + return 0;
> > > + }
> > > +
> > > + return -ENOSPC;
> >
> > Since it is executing under a mutex, and we already failed
> > 'if (ser->nr_devices == ser->max_nr_devices) check above, will we ever reach
> > here and return -ENOSPC?
>
> Yeah I wouldn't expect to ever reach here.
Will you be removing it or want to keep it just in case scenario?
>
> > > diff --git a/include/linux/kho/abi/pci.h b/include/linux/kho/abi/pci.h
> > > index 5c0e92588c00..5b4c8d9e462c 100644
> > > --- a/include/linux/kho/abi/pci.h
> > > +++ b/include/linux/kho/abi/pci.h
> > > @@ -23,19 +23,20 @@
> > > * incrementing the version number in the PCI_LUO_FLB_COMPATIBLE string.
> > > */
> > >
> > > -#define PCI_LUO_FLB_COMPATIBLE "pci-v1"
> > > +#define PCI_LUO_FLB_COMPATIBLE "pci-v2"
> >
> > Just curious, why did we change the version here?
>
> Because a field in struct pci_dev_ser changed.
>
> > It's not like just
> > previous patch is working enough to perform a live update. As the config
> > is experimental, can't we just keep it PCI-v1 for the whole series?
>
> What is the benefit of keeping "pci-v1"?
>
I don't see any benefit in keeping v1 or changing to v2 as well.
My reasoning is that before this series is merged, there is no real need
for versioning here. This is first series which is introducing PCI
liveupdate. It is not gonna be that someone has merged patch 1 only, run
its kernel and then kexec to next kernel which has patch 2.
> I think it makes sense to follow the rule we set which is to update
> the compatibility string in any commit that changes the ABI.
Okay, this is also fine.
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: (pmbus/lx1308) Add support for LX1308
From: Guenter Roeck @ 2026-04-30 18:18 UTC (permalink / raw)
To: Brian Chiang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260428-add-support-lx1308-v2-2-90f115954143@inventec.com>
On Tue, Apr 28, 2026 at 12:19:29PM +0000, Brian Chiang wrote:
> Add support for the Luxshare LX1308, a high-efficiency 12V 860W
> DC/DC power module. The module operates from 40-60V input voltage.
>
> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox