lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <KL1PR0601MB5773162A7800668486209FF6E6242@KL1PR0601MB5773.apcprd06.prod.outlook.com>
Date: Mon, 11 Mar 2024 12:13:50 +0000
From: Rex Nie <rex.nie@...uarmicro.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
CC: "james.morse@....com" <james.morse@....com>, "fenghua.yu@...el.com"
	<fenghua.yu@...el.com>, "reinette.chatre@...el.com"
	<reinette.chatre@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Liming Wu <liming.wu@...uar.com>
Subject:
 答复: 答复: [PATCH] fs/resctrl: fix domid loss precision issue

Hello,
	Reply as below.
Best regards
Rex

> -----邮件原件-----
> 发件人: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
> 发送时间: 2024年3月11日 19:50
> 收件人: Rex Nie <rex.nie@...uarmicro.com>
> 抄送: james.morse@....com; fenghua.yu@...el.com;
> reinette.chatre@...el.com; linux-kernel@...r.kernel.org; Liming Wu
> <liming.wu@...uar.com>
> 主题: Re: 答复: [PATCH] fs/resctrl: fix domid loss precision issue
> 
> External Mail: This email originated from OUTSIDE of the organization!
> Do not click links, open attachments or provide ANY information unless you
> recognize the sender and know the content is safe.
> 
> 
> Thanks for the reply,
> 
> On 2024-03-11 at 09:37:37 +0000, Rex Nie wrote:
> >Hello,
> >       Please kindly check my inline reply. Thanks.
> >Best regards
> >Rex Nie
> >
> >> >This will cause below issue if cache_id > 0x3fff likes:
> >>
> >> Is there some reason for cache_id ever being this high?
> >>
> >> I thought the max for cache_id was the amount of L3 caches on a
> >> system. And I only observed it going up to 3 on some server
> >> platforms. So not nearly in the range of 0x3fff or 16k.
> >>
> >It is exactly as you said on X86 platforms, but cache_Id on Arm platform is
> different.
> >According to ACPI for mpam, cache id is used as locator for cache MSC.
> Reference to RD_PPTT_CACHE_ID definition from edk2-platforms:
> >#define RD_PPTT_CACHE_ID(PackageId, ClusterId, CoreId, CacheType)
> \
> >
> (                                                              \
> >         (((PackageId) & 0xF) << 20) | (((ClusterId) & 0xFF) << 12) |
> \
> >         (((CoreId) & 0xFF) << 4) | ((CacheType) & 0xF)
> \
> >       )
> >So it may be > 0x3fff on Arm platform.
> >
> >Reference RD_PPTT_CACHE_ID from edk2-platforms:
> >https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Sg
> >iPkg/Include/SgiAcpiHeader.h#L202
> 
> and thanks for clearing it up for me! I browsed some MPAM patches but didn't
> notice cache_id was used differently on ARM.
> 
Yes, the mpam driver from kernel use the cache_id as component id, domid directly reported from mpam acpi table(struct acpi_table_mpam_msc_res->locator1),
so the use of cache_id in mpam driver is NO different, but the definition of cache_id, or how to generate cache_id from firmware side(UEFI) is different.

I take 2 commits from edk2-platforms of ARM FVP for your reference.
https://git.gitlab.arm.com/arm-reference-solutions/edk2-platforms/-/commit/d9f3290b0ba63dcc4b124017f6dede5afb681cbb
https://git.gitlab.arm.com/arm-reference-solutions/edk2-platforms/-/commit/08fe90e90a84c7ae074ddcfcfa58e73ea7c03a49


> >
> >> >/sys/fs/resctrl/mon_groups/p1/mon_data/mon_L3_1048564 # cat
> >> >llc_occupancy
> >>
> >> How did you get this file to appear? Could you maybe show how your
> >> mon_data directory looks like?
> >>
> >I found this issue on Arm FVP N1 platform and my N2 platform.
> >
> >Below is the steps on Arm FVP N1:
> >mount -t resctrl resctrl / /sys/fs/resctrl cd /sys/fs/resctrl/mon_data
> >
> >/sys/fs/resctrl/mon_data # ls -l
> >total 0
> >dr-xr-xr-x    2 0        0                0 Mar 11 09:24
> mon_L3_1048564
> >
> >cd /sys/fs/resctrl/mon_data # cd mon_L3_1048564
> >/sys/fs/resctrl/mon_data/mon_L3_1048564 # cat llc_occupancy
> >cat: read error: No such file or directory
> >
> >Arm FVP MPAM:
> >https://neoverse-reference-design.docs.arm.com/en/latest/mpam/mpam-res
> c
> >trl.html#memory-system-resource-partitioning-and-monitoring-mpam
> >
> 
> --
> Kind regards
> Maciej Wieczór-Retman

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ