Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 11月, 2022 13 次提交
  3. 22 11月, 2022 5 次提交
    • O
      !229 Intel SPR: Adding uncore PMU support and fix uprobes rbtree usage for OLK-5.10 · 1b709179
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @allen-shi 
 
This is a cherry-pick of [PR82](https://gitee.com/openeuler/kernel/pulls/82) and [PR120](https://gitee.com/openeuler/kernel/pulls/120) from openEuler-22.09 branch.
[PR120](https://gitee.com/openeuler/kernel/pulls/120) is to fix the issue for [PR82](https://gitee.com/openeuler/kernel/pulls/82).

### For [PR82](https://gitee.com/openeuler/kernel/pulls/82), the patch set is to add uncore PMU support for Intel Sapphire Rapids platform.

It includes generic uncore discovery support and SPR specific uncore event support.

Generic uncore discovery support contains:
a) Feature patches from upstream 5.13-rc1(5 commits):
c4c55e36 perf/x86/intel/uncore: Generic support for the MMIO type of uncore blocks
42839ef4 perf/x86/intel/uncore: Generic support for the PCI type of uncore blocks
6477dc39 perf/x86/intel/uncore: Rename uncore_notifier to uncore_pci_sub_notifier
d6c75413 perf/x86/intel/uncore: Generic support for the MSR type of uncore blocks
edae1f06 perf/x86/intel/uncore: Parse uncore discovery tables

b) To fix rb_find/rb_add implicit declaration errors, adding rbtree helper patches(v5.12-rc1, 7 commits):
798172b1 rbtree, timerqueue: Use rb_add_cached()
5a798725 rbtree, rtmutex: Use rb_add_cached()
a905e84e rbtree, uprobes: Use rbtree helpers
a3b89864 rbtree, perf: Use new rbtree helpers
8ecca394 rbtree, sched/deadline: Use rb_add_cached()
bf9be9a1 rbtree, sched/fair: Use rb_add_cached()
2d24dd57 rbtree: Add generic add and find helpers

c) To fix error(too few arguments to function ‘uncore_pci_pmu_register’), add dependent patches(5.12-rc1, 2):
9a7832ce perf/x86/intel/uncore: With > 8 nodes, get pci bus die id from NUMA info
ba9506be perf/x86/intel/uncore: Store the logical die id instead of the physical die id.

SPR platform specific uncore support contains:
a) Feature upstream patches from mainline v5.15-rc1(15 commits):
c76826a6 perf/x86/intel/uncore: Support IMC free-running counters on Sapphire Rapids server
0378c93a perf/x86/intel/uncore: Support IIO free-running counters on Sapphire Rapids server
1583971b perf/x86/intel/uncore: Factor out snr_uncore_mmio_map()
8053f2d7 perf/x86/intel/uncore: Add alias PMU name
0d771caf perf/x86/intel/uncore: Add Sapphire Rapids server MDF support
2a8e51ea perf/x86/intel/uncore: Add Sapphire Rapids server M3UPI support
da5a9156 perf/x86/intel/uncore: Add Sapphire Rapids server UPI support
f57191ed perf/x86/intel/uncore: Add Sapphire Rapids server M2M support
85f2e30f perf/x86/intel/uncore: Add Sapphire Rapids server IMC support
0654dfdc perf/x86/intel/uncore: Add Sapphire Rapids server PCU support
f85ef898 perf/x86/intel/uncore: Add Sapphire Rapids server M2PCIe support
e199eb51 perf/x86/intel/uncore: Add Sapphire Rapids server IRP support
3ba7095b perf/x86/intel/uncore: Add Sapphire Rapids server IIO support
949b1138 perf/x86/intel/uncore: Add Sapphire Rapids server CHA support
c54c53d9 perf/x86/intel/uncore: Add Sapphire Rapids server framework

b) Two SPR model name related changes to make above patches apply cleanly(2 commits):
(5.14-rc2) 28188cc4 x86/cpu: Fix core name for Sapphire Rapids
(5.13-rc1) 53375a5a x86/cpu: Resort and comment Intel models

c) Some SPR uncore related bugfixes(6 commits):
v5.16-rc1:
4034fb20 perf/x86/intel/uncore: Fix Intel SPR M3UPI event constraints
f01d7d55 perf/x86/intel/uncore: Fix Intel SPR M2PCIE event constraints
67c5d443 perf/x86/intel/uncore: Fix Intel SPR IIO event constraints
9d756e40 perf/x86/intel/uncore: Fix Intel SPR CHA event constraints
e2bb9fab perf/x86/intel/uncore: Fix invalid unit check
v5.13-rc6:
4a0e3ff3 perf/x86/intel/uncore: Fix a kernel WARNING triggered by maxcpus=1

 **Intel-kernel issue:** 
[#I5BECO](https://gitee.com/openeuler/intel-kernel/issues/I5BECO)

 **Test:** 
With this patch set, on SPR:

```
# cat /sys/devices/uncore_cha_1/alias
uncore_type_0_1
# perf stat -a -e uncore_imc_0/event=0x1/ -- sleep 1

 Performance counter stats for 'system wide':

     2,407,096,566      uncore_imc_0/event=0x1/

       1.002850766 seconds time elapsed
# perf stat -a -e uncore_imc_free_running_0/rpq_cycles/ -- sleep 1

 Performance counter stats for 'system wide':

        13,879,446      uncore_imc_free_running_0/rpq_cycles/

       1.002852701 seconds time elapsed
```

Without this patch set, the "uncore_cha_1" like devices are not available under /sys/devices, and the above like uncore events will be "not supported".

 **Known issue:** 
N/A

 **Default config change:** 
N/A



### For [PR120](https://gitee.com/openeuler/kernel/pulls/120), it is to cherry-pick upstream fix for commit c6bc9bd06dff ("rbtree, uprobes: Use rbtree helpers")

 **BPFTrace Issue** 
[#I5RUM5](https://gitee.com/src-openeuler/bpftrace/issues/I5RUM5)

 **Tests** 
1, run bpftrace /usr/share/bpftrace/tools/bashreadline.bt without the fix, we can see the core dump
2, Apply the fix, and run bpftrace /usr/share/bpftrace/tools/bashreadline.bt, the issue disappears.

 **Known Issue** 
N/A

 **Default config change** 
N/A 
 
Link:https://gitee.com/openeuler/kernel/pulls/229 
Reviewed-by: Jun Tian <jun.j.tian@intel.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      1b709179
    • O
      !251 [OLK-5.10] arm64: add machine checksafe support · fd124538
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @ma-wupeng 
 
With the increase of memory capacity and density, the probability of
memory error increases. The increasing size and density of server RAM
in the data center and cloud have shown increased uncorrectable memory
errors.

Currently, the kernel has a mechanism to recover from hardware memory
errors. This patchset provides an new recovery mechanism.

For arm64, the hardware memory error handling is do_sea() which divided
into two cases:

The user state consumed the memory errors, the solution is kill the
user process and isolate the error page.
The kernel state consumed the memory errors, the solution is panic.
For case 2, Undifferentiated panic maybe not the optimal choice, it can be
handled better, in some scenarios, we can avoid panic, such as uaccess, if
the uaccess fails due to memory error, only the user process will be affected,
kill the user process and isolate the user page with hardware memory errors
is a better choice.

PR form 22.09:  
 
Link:https://gitee.com/openeuler/kernel/pulls/251 
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      fd124538
    • O
      !54 configs: change the value of NLS_CODEPAGE_437 from m to y · d8dfe441
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @hifi521 
 
#I5JMOU 
If the NLS_CODEPAGE_437.ko does not exist in the bootrom system, but the
vfat filesystem depends on the NLS_CODEPAGE_437 module, the /boot/efi fails
to be mounted.
Change the value of NLS_CODEPAGE_437 from m to y in arch/arm64/configs
/openeuler_defconfig and arch/x86/configs/openeuler_defconfig. 
 
Link:https://gitee.com/openeuler/kernel/pulls/54 
Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
      d8dfe441
    • O
      !255 ksmbd-introduce-new-SMB3-kernel-server · 03e3dd19
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @zhongjinghua 
 
KSMBD support.

KSMBD is an opensource In-kernel CIFS/SMB3 server created by Namjae Jeon for Linux Kernel. It's an implementation of SMB/CIFS protocol in kernel space for sharing files and IPC services over network. Initially the target is to provide improved file I/O performances, but the bigger goal is to have some new features which are much easier to develop and maintain inside the kernel and expose the layers fully. Directions can be attributed to sections where SAMBA is moving to few modules inside the kernel to have features like RDMA(Remote direct memory access) to work with actual performance gain.

issue:
https://e.gitee.com/open_euler/dashboard?issue=I60T7G 
 
Link:https://gitee.com/openeuler/kernel/pulls/255 
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
      03e3dd19
    • O
      !262 crypto: enable some SM configs · 856f3f97
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @HuaxinLuGitee 
 
openeuler inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6202L
CVE: NA

1. set CONFIG_CRYPTO_SM2/3 to y:
The module signature based on SM2 cert has been supported now.
So the SM2/3 should be enabled by default to support SM2 cert
in kernel boot process.

2. set CONFIG_CRYPTO_SM3_GENERIC to y:
sm3-generic is architecture independent and should be build
in case other modules fail.

3. set CONFIG_CRYPTO_SM4_GENERIC to m:
sm4-generic is architecture independent and should be build
in case other modules fail.

4. enable algorithm implementations related to architecture:
Enable SM4-CE, SM4-NEON, SM3-AVX to imporve algorithm
performance.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/262 
Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
      856f3f97
  5. 21 11月, 2022 22 次提交