[PATCH v2 OLK-5.10 0/4] arm64/mpam: enable MPAM feature and
Enabling the MPAM feature and some bugfixes in OLK-5.10. Quanmin Yan (2): arm64/mpam: only allow L3 cache MPAM device created arm64/mpam: fix the bitmap written during mpam device reset Zeng Heng (2): arm64/mpam: set default feedback of last_cmd_status interface as null string arm64/mpam: fix inadvertently updating after repeatedly updating arch/arm64/kernel/mpam/mpam_ctrlmon.c | 2 +- arch/arm64/kernel/mpam/mpam_device.c | 10 +++++++--- arch/arm64/kernel/mpam/mpam_resctrl.c | 2 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- drivers/acpi/arm64/mpam_v2.c | 8 ++++++++ 5 files changed, 18 insertions(+), 6 deletions(-) -- 2.43.0
From: Zeng Heng <zengheng4@huawei.com> hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8421 ---------------------------------------- Set default feedback of last_cmd_status interface as null string, in case misunderstanding the execution result of the previous command. Fixes: e37caef15c18 ("resctrlfs: mpam: Build basic framework for mpam") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com> --- arch/arm64/kernel/mpam/mpam_resctrl.c | 2 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/mpam/mpam_resctrl.c b/arch/arm64/kernel/mpam/mpam_resctrl.c index 8364b3f8b7b3..b3cc8c709787 100644 --- a/arch/arm64/kernel/mpam/mpam_resctrl.c +++ b/arch/arm64/kernel/mpam/mpam_resctrl.c @@ -1711,7 +1711,7 @@ static int resctrl_last_cmd_status_show(struct kernfs_open_file *of, if (len) seq_printf(seq, "%.*s", len, last_cmd_status_buf); else - seq_puts(seq, "ok\n"); + seq_puts(seq, ""); mutex_unlock(&resctrl_group_mutex); return 0; } diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c index c7ca13ad09fc..db9cb9dbfb72 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -838,7 +838,7 @@ static int rdt_last_cmd_status_show(struct kernfs_open_file *of, if (len) seq_printf(seq, "%.*s", len, last_cmd_status_buf); else - seq_puts(seq, "ok\n"); + seq_puts(seq, ""); mutex_unlock(&rdtgroup_mutex); return 0; } -- 2.43.0
From: Zeng Heng <zengheng4@huawei.com> hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8421 -------------------------------- After repeatedly updating control group A's configuration, creating a monitoring subgroup under a different control group B inadvertently changes B's settings. The root cause is that every schemata writing operation sets ctrl_updated true via the parse_ctrlval() callback. When the identical configuration is written again, resctrl_group_update_domain_ctrls() would not resets ctrl_updated to false. As a result, while creating a monitoring group under any other control group, the configuration sync logic mis-detects a pending update and incorrectly propagates the stale values. Therefore, even no actual change is detected, resctrl_group_update_domain_ctrls() also needs restore ctrl_updated to false. Fixes: 3dc904091153 ("[Huawei] arm64/mpam_ctrlmon: Update ctrl group config with rdtgrp's partid") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com> --- arch/arm64/kernel/mpam/mpam_ctrlmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/mpam/mpam_ctrlmon.c b/arch/arm64/kernel/mpam/mpam_ctrlmon.c index d1a7b07114ab..ee057a14f115 100644 --- a/arch/arm64/kernel/mpam/mpam_ctrlmon.c +++ b/arch/arm64/kernel/mpam/mpam_ctrlmon.c @@ -269,9 +269,9 @@ static void resctrl_group_update_domain_ctrls(struct rdtgroup *rdtgrp, dom->ctrl_val[type][closid.intpartid] = cfg[i].new_ctrl[type]; dom->have_new_ctrl = true; - cfg[i].ctrl_updated[type] = false; update_on = true; } + cfg[i].ctrl_updated[type] = false; } if (update_on) resctrl_dom_ctrl_config(cdp_both_ctrl, r, dom, ¶); -- 2.43.0
hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/8421 ------------------------------------------ In some ACPI versions, cache information (such as L2) other than L3 is reported. Due to the fact that the 5.10 MPAM ACPI does not support parsing the CPU affinity information of the msc, and therefore does not support the mounting of the L2 function. As a result, an error occurs when the device is detected subsequently. The mpam of the current 5.10 kernel version provides only L3 cache-related functions. Therefore, when parsing ACPI, only the mpam device of the L3 cache can be created to avoid the preceding problem. Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com> --- drivers/acpi/arm64/mpam_v2.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/acpi/arm64/mpam_v2.c b/drivers/acpi/arm64/mpam_v2.c index 6a9a4d013380..899aee1ab76e 100644 --- a/drivers/acpi/arm64/mpam_v2.c +++ b/drivers/acpi/arm64/mpam_v2.c @@ -77,6 +77,14 @@ static int __init acpi_mpam_parse_cache_v2(struct acpi_mpam_msc_node *msc, ci = NULL; cpus_read_unlock(); + /* + * 5.10 MPAM ACPI does not support parsing the CPU affinity + * information of the msc, and therefore the L2 devices + * cannot be created. + */ + if (level != 3) + return 0; + /* * Possible we can get cpu-affinity in next MPAM ACPI version, * now we have to set it to NULL and use default possible_aff- -- 2.43.0
hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8421 ------------------------------------------ In the mpam_reset_device_bitmap, wd indicates the bit width. The original logic directly converts it into a bitmap, which is incorrect. As a result, the bit width of the bitmap is one bit more than the actual bit width. After resctrl is mounted again, the schemata read is not as expected. Fix it by subtracting 1 from wb before GENMASK is performed. Fixes: 675345bc2866 ("arm64/mpam: Reset controls when CPUs come online") Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com> --- arch/arm64/kernel/mpam/mpam_device.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/mpam/mpam_device.c b/arch/arm64/kernel/mpam/mpam_device.c index deaf990d0c74..7de8e2cd8bd9 100644 --- a/arch/arm64/kernel/mpam/mpam_device.c +++ b/arch/arm64/kernel/mpam/mpam_device.c @@ -911,7 +911,7 @@ int mpam_discovery_start(void) static void mpam_reset_device_bitmap(struct mpam_device *dev, u16 reg, u16 wd) { - u32 bm = ~0; + u32 msb, bm = ~0; int i; lockdep_assert_held(&dev->lock); @@ -920,8 +920,12 @@ static void mpam_reset_device_bitmap(struct mpam_device *dev, u16 reg, u16 wd) for (i = 0; i < wd / 32; i++, reg += sizeof(bm)) mpam_write_reg(dev, reg, bm); - /* and the last partial 32bit word */ - bm = GENMASK(wd % 32, 0); + /* + * ....and the last partial 32bit word. When wd is a multiple + * of 32, msb should be 31 to write a full 32bit word. + */ + msb = (wd - 1) % 32; + bm = GENMASK(msb, 0); if (bm) mpam_write_reg(dev, reg, bm); } -- 2.43.0
反馈： 您发送到kernel@openeuler.org的补丁/补丁集，已成功转换为PR！ PR链接地址： https://atomgit.com/openeuler/kernel/merge_requests/21072 邮件列表地址：https://mailweb.openeuler.org/archives/list/kernel@openeuler.org/message/X3L... FeedBack: The patch(es) which you have sent to kernel@openeuler.org mailing list has been converted to a pull request successfully! Pull request link: https://atomgit.com/openeuler/kernel/merge_requests/21072 Mailing list address: https://mailweb.openeuler.org/archives/list/kernel@openeuler.org/message/X3L...
participants (2)
-
patchwork bot -
Quanmin Yan