maillist inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5K0NK
CVE: NA

Reference: https://patchwork.kernel.org/project/netdevbpf/patch/20220924080157.247678-1-liujian56@huawei.com/

--------------------------------

The following warning is displayed when the tcp6-multi-diffip11 stress
test case of the LTP test suite is tested:

watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]
CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : des3_ede_encrypt+0x27c/0x460 [libdes]
lr : 0x3f
sp : ffff80000ceaa1b0
x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280
x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b
x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038
x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033
x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248
x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548
x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748
x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b
x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3
x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872
Call trace:
 des3_ede_encrypt+0x27c/0x460 [libdes]
 crypto_des3_ede_encrypt+0x1c/0x30 [des_generic]
 crypto_cbc_encrypt+0x148/0x190
 crypto_skcipher_encrypt+0x2c/0x40
 crypto_authenc_encrypt+0xc8/0xfc [authenc]
 crypto_aead_encrypt+0x2c/0x40
 echainiv_encrypt+0x144/0x1a0 [echainiv]
 crypto_aead_encrypt+0x2c/0x40
 esp6_output_tail+0x1c8/0x5d0 [esp6]
 esp6_output+0x120/0x278 [esp6]
 xfrm_output_one+0x458/0x4ec
 xfrm_output_resume+0x6c/0x1f0
 xfrm_output+0xac/0x4ac
 __xfrm6_output+0x130/0x270
 xfrm6_output+0x60/0xec
 ip6_xmit+0x2ec/0x5bc
 inet6_csk_xmit+0xbc/0x10c
 __tcp_transmit_skb+0x460/0x8c0
 tcp_write_xmit+0x348/0x890
 __tcp_push_pending_frames+0x44/0x110
 tcp_rcv_established+0x3c8/0x720
 tcp_v6_do_rcv+0xdc/0x4a0
 tcp_v6_rcv+0xc24/0xcb0
 ip6_protocol_deliver_rcu+0xf0/0x574
 ip6_input_finish+0x48/0x7c
 ip6_input+0x48/0xc0
 ip6_rcv_finish+0x80/0x9c
 xfrm_trans_reinject+0xb0/0xf4
 tasklet_action_common.constprop.0+0xf8/0x134
 tasklet_action+0x30/0x3c
 __do_softirq+0x128/0x368
 do_softirq+0xb4/0xc0
 __local_bh_enable_ip+0xb0/0xb4
 put_cpu_fpsimd_context+0x40/0x70
 kernel_neon_end+0x20/0x40
 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce]
 sha1_ce_finup+0x94/0x110 [sha1_ce]
 crypto_shash_finup+0x34/0xc0
 hmac_finup+0x48/0xe0
 crypto_shash_finup+0x34/0xc0
 shash_digest_unaligned+0x74/0x90
 crypto_shash_digest+0x4c/0x9c
 shash_ahash_digest+0xc8/0xf0
 shash_async_digest+0x28/0x34
 crypto_ahash_digest+0x48/0xcc
 crypto_authenc_genicv+0x88/0xcc [authenc]
 crypto_authenc_encrypt+0xd8/0xfc [authenc]
 crypto_aead_encrypt+0x2c/0x40
 echainiv_encrypt+0x144/0x1a0 [echainiv]
 crypto_aead_encrypt+0x2c/0x40
 esp6_output_tail+0x1c8/0x5d0 [esp6]
 esp6_output+0x120/0x278 [esp6]
 xfrm_output_one+0x458/0x4ec
 xfrm_output_resume+0x6c/0x1f0
 xfrm_output+0xac/0x4ac
 __xfrm6_output+0x130/0x270
 xfrm6_output+0x60/0xec
 ip6_xmit+0x2ec/0x5bc
 inet6_csk_xmit+0xbc/0x10c
 __tcp_transmit_skb+0x460/0x8c0
 tcp_write_xmit+0x348/0x890
 __tcp_push_pending_frames+0x44/0x110
 tcp_push+0xb4/0x14c
 tcp_sendmsg_locked+0x71c/0xb64
 tcp_sendmsg+0x40/0x6c
 inet6_sendmsg+0x4c/0x80
 sock_sendmsg+0x5c/0x6c
 __sys_sendto+0x128/0x15c
 __arm64_sys_sendto+0x30/0x40
 invoke_syscall+0x50/0x120
 el0_svc_common.constprop.0+0x170/0x194
 do_el0_svc+0x38/0x4c
 el0_svc+0x28/0xe0
 el0t_64_sync_handler+0xbc/0x13c
 el0t_64_sync+0x180/0x184

Get softirq info by bcc tool:
./softirqs -NT 10
Tracing soft irq event time... Hit Ctrl-C to end.

15:34:34
SOFTIRQ          TOTAL_nsecs
block                 158990
timer               20030920
sched               46577080
net_rx             676746820
tasklet           9906067650

15:34:45
SOFTIRQ          TOTAL_nsecs
block                  86100
sched               38849790
net_rx             676532470
timer             1163848790
tasklet           9409019620

15:34:55
SOFTIRQ          TOTAL_nsecs
sched               58078450
net_rx             475156720
timer              533832410
tasklet           9431333300

The tasklet software interrupt takes too much time. Therefore, the
xfrm_trans_reinject executor is changed from tasklet to workqueue. Add add
spin lock to protect the queue. This reduces the processing flow of the
tcp_sendmsg function in this scenario.

Fixes: acf568ee ("xfrm: Reinject transport-mode packets through tasklet")
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

Conflicts:
	net/xfrm/xfrm_input.c
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S
CVE: NA

--------------------------------

Commit bc25b308 ("mm: reliable: Use EINVAL in reliable_check") update
EPERM to EINVAL try to pass LTP's proc01 test, however LTP only treat
EACCESS as whitelist in the scenario.

To solve this problem, update EINVAL to EACCESS.

Fixes: bc25b308 ("mm: reliable: Use EINVAL in reliable_check")
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NChen Wandun <chenwandun@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S
CVE: NA

--------------------------------

LTP's proc01 test was failing be because this ret code (1):

	proc01      1  TFAIL  :  proc01.c:400: read failed: /proc/self/task/1406366/reliable: errno=EPERM(1): Operation not permitted

To slove this problem, replace EPERM with EINVAL in reliable_check().
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.122
commit 7fa8312879f78d255a63b372473a7016d4c29d67
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6D4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7fa8312879f78d255a63b372473a7016d4c29d67

--------------------------------

[ Upstream commit 9c90c9b3 ]

This reverts commit 4dc2a5a8.

A non-zero return value from pfkey_broadcast() does not necessarily mean
an error occurred as this function returns -ESRCH when no registered
listener received the message. In particular, a call with
BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return
zero so that this commit in fact prevents processing any PF_KEY message.
One visible effect is that racoon daemon fails to find encryption
algorithms like aes and refuses to start.

Excluding -ESRCH return value would fix this but it's not obvious that
we really want to bail out here and most other callers of
pfkey_broadcast() also ignore the return value. Also, as pointed out by
Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code
should use netlink instead so that we should only disturb the code for
really important fixes.

v2: add a comment explaining why is the return value ignored
Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

Merge Pull Request from: @jiayingbao 
 
Sapphire Rapids uncore frequency control is the same as Skylake and
Ice Lake. Add the Sapphire Rapids CPU model number to the match array.

backport upstream patch without change. 
 
Link:https://gitee.com/openeuler/kernel/pulls/125 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

mainline inclusion
from mainline-5.11
commit 60accc01
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5SML7
CVE: NA

Intel-SIG: commit 60accc01 platform/x86/intel-uncore-freq: Add
Sapphire Rapids server support
Backport for intel-uncore-freq Sapphire Rapids server support

-------------------------------------------------

Sapphire Rapids uncore frequency control is the same as Skylake and
Ice Lake. Add the Sapphire Rapids CPU model number to the match array.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Reviewed-by: NTony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210203114320.1398801-1-dedekind1@gmail.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: yingbao jia<yingbao.jia@intel.com>

Merge Pull Request from: @kmf 
 
 This is required to support ppc64le.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/118 
Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @haochengxie 
 
Add new perf features, backporting these patches from mainline:
1.Performance Monitor Global Controls
2.IBS（Instrument Based Sample）extensions
3.BRS(Branch Sample)

Patches been relied:
69372cf0   5.11   x86/cpu: Add VM page flush MSR availablility as a CPUID feature
fb35d30f   5.12   x86/cpufeatures: Assign dedicated feature word for CPUID_0x8000001F[EAX]

Perf BRS:
bfe4daf8   5.19   perf/core: Add perf_clear_branch_entry_bitfields() helper
a77d41ac   5.19   x86/cpufeatures: Add AMD Fam19h Branch Sampling feature
ada54345   5.19   perf/x86/amd: Add AMD Fam19h Branch Sampling support
44175993   5.19   perf/x86/amd: Add branch-brs helper event for Fam19h BRS
8910075d   5.19   perf/x86/amd: Enable branch sampling priv level filtering
ba2fe750   5.19   perf/x86/amd: Add AMD branch sampling period adjustment
cc37e520   5.19   perf/x86/amd: Make Zen3 branch sampling opt-in
2a606a18   5.19   ACPI: Add perf low power callback
d5616bac   5.19   perf/x86/amd: Add idle hooks for branch sampling

PerfmonV2 controls:
d6d0c7f6
089be16d
21d59e3e
56e026a7   5.19-rc1    PerfmonV2 Controls for Core PMU series
9622e67e
7685665c
bae19fdd  

Perf IBS:
6a371baf   5.15       perf/x86/amd/ibs: Add bitfield definitions in new <asm/amd-ibs.h> header
3d47083b   5.19       perf/amd/ibs: Use interrupt regs ip for stack unwinding
39b2ca75   5.19       perf/amd/ibs: Cascade pmu init functions' return value
2a7a7e65   5.19       perf/amd/ibs: Use ->is_visible callback for dynamic attributes
ba5d35b4   5.19-rc1   perf/amd/ibs: Add support for L3 miss filtering
838de1d8   5.19-rc1   perf/amd/ibs: Advertise zen4_ibs_extensions as pmu capability attribute
 
 
Link:https://gitee.com/openeuler/kernel/pulls/119 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @x56Jason 
 
This PR is to cherry-pick upstream fix for commit c6bc9bd06dff ("rbtree, uprobes: Use rbtree helpers")

BPFTrace Issue
#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/120 
Reviewed-by: Xu Kuohai <xukuohai@huawei.com> 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @zhengzengkai 
 
Pull fix commits for sched-programmable feature:
- Fix NULL pointer dereference error in helpers bpf_sched_entity_to_cgrpid() and bpf_sched_entity_belongs_to_cgrp()
- Fix build error 'stack exceeds 512 bytes' of sample 'sched_select_core' 
 
Link:https://gitee.com/openeuler/kernel/pulls/117 
Reviewed-by: Xu Kuohai <xukuohai@huawei.com> 

mainline inclusion
from mainline-5.12-rc1
commit b0d6d478
category: bugfix
bugzilla: https://gitee.com/src-openeuler/bpftrace/issues/I5RUM5
CVE: N/A

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0d6d4789677d128b1933af023083054f0973574

-------------------------------------------------

commit c6bc9bd06dff ("rbtree, uprobes: Use rbtree helpers")
accidentally removed the refcount increase. Add it again.

Fixes: c6bc9bd06dff ("rbtree, uprobes: Use rbtree helpers")
Signed-off-by: NSven Schnelle <svens@linux.ibm.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lkml.kernel.org/r/20210209150711.36778-1-svens@linux.ibm.comSigned-off-by: NJason Zeng <jason.zeng@intel.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5QQFG
CVE: NA

--------------------------------

The pointer which is tg->css.cgroup may be NULL.
To avoid NULL pointer dereference error, add a check in
bpf_sched_entity_to_cgrpid() and bpf_sched_entity_belongs_to_cgrp().

Fixes: 628738d6 ("bpf: sched: add convenient helpers to identify sched entities")
Signed-off-by: NRen Zhijie <renzhijie2@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5RMFU
CVE: NA

--------------------------------

1.Change arg type of 'bpf_get_cpumask_info' to avoid
  bpf program stack exceeds 512 bytes.
2.Fix back-edge error in sample 'sched_select_core'
3.Fix loop too complex in sample 'sached_select_core'

Changes in v2:
  Move cpu initialization out of the for loop.

Fixes: 1bf0417b ("sched: programmable: Add helper function for cpu topo...")
Fixes: 2c1189e3 ("samples:bpf: Add samples for cfs select core")
Signed-off-by: NHui Tang <tanghui20@huawei.com>

Merge Pull Request from: @zzmine 
 
This patchset incorporates the page table check functionality supported in the linux community into openEuler 22.09.
The patchset includes:
1. 核心功能及x86支持

d283d422 x86: mm: add x86_64 support for page table check
df4e817b mm: page table check
08d5b29e mm: ptep_clear() page table helper
1eba86c0 mm: change page type prior to adding page table entry

2.  bugfix补丁

80110bbf mm/page_table_check: check entries at pmd levels
e59a47b8 mm/khugepaged: unify collapse pmd clear, flush and free
64d8b9e1 mm/page_table_check: use unsigned long for page counters 
and cleanup
fb5222aa mm/debug_vm_pgtable: remove pte entry from the page 
table    【5.10不涉及】


3.  arm64支持

42b25471 arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK
2e7dc2b6 mm: remove __HAVE_ARCH_PTEP_CLEAR in pgtable.h
de8c8e52 mm: page_table_check: add hooks to public helpers
e5a55401 mm: page_table_check: move pxx_user_accessible_page into x86
92fb0524 mm: page_table_check: using PxD_SIZE instead of PxD_PAGE_SIZE

4. bugfix补丁

ed928a34 arm64/mm: fix page table check compile error for 
CONFIG_PGTABLE_LEVELS=2

Intel Kernel Issue
openEuler5.10内核支持页表检查功能（page table check）

Test
Build and boot kernel successfully.
Build with PAGE_TABLE_CHECK=y and boot with page_table_check=on kernel parameter. 
 
Link:https://gitee.com/openeuler/kernel/pulls/114 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @allen-shi 
 
This PR is to add KVM support for Bus Lock Debug Exception.

Intel-Kernel Issue
[#I5RHW7](https://gitee.com/openeuler/intel-kernel/issues/I5RHW7)

Test
Guest supports for Bus Lock Debug Exception feature.

Known Issue
N/A

Default config change
N/A 
 
Link:https://gitee.com/openeuler/kernel/pulls/115 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @allen-shi 
 
Virtual machines can exploit Intel ISA characteristics to cause
functional denial of service to the VMM. Introduce a new
feature named Notify VM exit, which can help mitigate such kind of
attacks.

Intel-kernel issue:
[#I5PAJ5:SPR:KVM:Notify VM exit](https://gitee.com/openeuler/intel-kernel/issues/I5PAJ5)

Test:
1. KVM Sanity Test
2. run the kernel normally on OpenEuler 22.03 LTS

Known issue:
N/A 
 
Link:https://gitee.com/openeuler/kernel/pulls/109 
Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

mainline inclusion
from mainline-v6.0-rc1
commit 8deb03e7
category: feature
feature: Notify VM exit
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5PAJ5
CVE: N/A
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=8deb03e7

Intel-SIG: commit 8deb03e7 ("KVM: Fix references to non-existent KVM_CAP_TRIPLE_FAULT_EVENT")

-------------------------------------

KVM: Fix references to non-existent KVM_CAP_TRIPLE_FAULT_EVENT

The x86-only KVM_CAP_TRIPLE_FAULT_EVENT was (appropriately) renamed to
KVM_CAP_X86_TRIPLE_FAULT_EVENT when the patches were applied, but the
docs and selftests got left behind.  Fix them.
Signed-off-by: NSean Christopherson <seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAichun Shi <aichun.shi@intel.com>

mainline inclusion
from mainline-v6.0-rc1
commit 2f4073e0
category: feature
feature: Notify VM exit
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5PAJ5
CVE: N/A
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=2f4073e0

Intel-SIG: commit 2f4073e0 ("KVM: VMX: Enable Notify VM exit")

-------------------------------------

KVM: VMX: Enable Notify VM exit

There are cases that malicious virtual machines can cause CPU stuck (due
to event windows don't open up), e.g., infinite loop in microcode when
nested #AC (CVE-2015-5307). No event window means no event (NMI, SMI and
IRQ) can be delivered. It leads the CPU to be unavailable to host or
other VMs.

VMM can enable notify VM exit that a VM exit generated if no event
window occurs in VM non-root mode for a specified amount of time (notify
window).

Feature enabling:
- The new vmcs field SECONDARY_EXEC_NOTIFY_VM_EXITING is introduced to
  enable this feature. VMM can set NOTIFY_WINDOW vmcs field to adjust
  the expected notify window.
- Add a new KVM capability KVM_CAP_X86_NOTIFY_VMEXIT so that user space
  can query and enable this feature in per-VM scope. The argument is a
  64bit value: bits 63:32 are used for notify window, and bits 31:0 are
  for flags. Current supported flags:
  - KVM_X86_NOTIFY_VMEXIT_ENABLED: enable the feature with the notify
    window provided.
  - KVM_X86_NOTIFY_VMEXIT_USER: exit to userspace once the exits happen.
- It's safe to even set notify window to zero since an internal hardware
  threshold is added to vmcs.notify_window.

VM exit handling:
- Introduce a vcpu state notify_window_exits to records the count of
  notify VM exits and expose it through the debugfs.
- Notify VM exit can happen incident to delivery of a vector event.
  Allow it in KVM.
- Exit to userspace unconditionally for handling when VM_CONTEXT_INVALID
  bit is set.

Nested handling
- Nested notify VM exits are not supported yet. Keep the same notify
  window control in vmcs02 as vmcs01, so that L1 can't escape the
  restriction of notify VM exits through launching L2 VM.

Notify VM exit is defined in latest Intel Architecture Instruction Set
Extensions Programming Reference, chapter 9.2.
Co-developed-by: NXiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: NXiaoyao Li <xiaoyao.li@intel.com>
Signed-off-by: NTao Xu <tao3.xu@intel.com>
Co-developed-by: NChenyi Qiang <chenyi.qiang@intel.com>
Signed-off-by: NChenyi Qiang <chenyi.qiang@intel.com>
Message-Id: <20220524135624.22988-5-chenyi.qiang@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAichun Shi <aichun.shi@intel.com>

mainline inclusion
from mainline-v5.15
commit 838de1d8
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

PMU driver can advertise certain feature via capability attribute('caps'
sysfs directory) which can be consumed by userspace tools like perf. Add
zen4_ibs_extensions capability attribute for IBS pmus. This attribute
will be enabled when CPUID_Fn8000001B_EAX[11] is set.

With patch on Zen4:

  $ ls /sys/bus/event_source/devices/ibs_op/caps
  zen4_ibs_extensions
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220509044914.1473-5-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit ba5d35b4
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

IBS L3 miss filtering works by tagging an instruction on IBS counter
overflow and generating an NMI if the tagged instruction causes an L3
miss. Samples without an L3 miss are discarded and counter is reset
with random value (between 1-15 for fetch pmu and 1-127 for op pmu).
This helps in reducing sampling overhead when user is interested only
in such samples. One of the use case of such filtered samples is to
feed data to page-migration daemon in tiered memory systems.

Add support for L3 miss filtering in IBS driver via new pmu attribute
"l3missonly". Example usage:

  # perf record -a -e ibs_op/l3missonly=1/ --raw-samples sleep 5
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220509044914.1473-4-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 2a7a7e65
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Currently, some attributes are added at build time whereas others
at boot time depending on IBS pmu capabilities. Instead, we can
just add all attribute groups at build time but hide individual
group at boot time using more appropriate ->is_visible() callback.

Also, struct perf_ibs has bunch of fields for pmu attributes which
just pass on the pointer, does not do anything else. Remove them.
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220509044914.1473-3-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 39b2ca75
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

IBS pmu initialization code ignores return value provided by
callee functions. Fix it.
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220509044914.1473-2-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 3d47083b
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

IbsOpRip is recorded when IBS interrupt is triggered. But there is
a skid from the time IBS interrupt gets triggered to the time the
interrupt is presented to the core. Meanwhile processor would have
moved ahead and thus IbsOpRip will be inconsistent with rsp and rbp
recorded as part of the interrupt regs. This causes issues while
unwinding stack using the ORC unwinder as it needs consistent rip,
rsp and rbp. Fix this by using rip from interrupt regs instead of
IbsOpRip for stack unwinding.

Fixes: ee9f8fce ("x86/unwind: Add the ORC unwinder")
Reported-by: NDmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Suggested-by: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20220429051441.14251-1-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 6a371baf
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add <asm/amd-ibs.h> with bitfield definitions for IBS MSRs,
and demonstrate usage within the driver.

Also move 'struct perf_ibs_data' where it can be shared with
the perf tool that will soon be using it.

No functional changes.
Signed-off-by: NKim Phillips <kim.phillips@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210817221048.88063-9-kim.phillips@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit bae19fdd
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Commit 1018faa6 ("perf/x86/kvm: Fix Host-Only/Guest-Only
counting with SVM disabled") addresses an issue in which the
Host-Only bit in the counter control registers needs to be
masked off when SVM is not enabled.

The events need to be reloaded whenever SVM is enabled or
disabled for a CPU and this requires the PERF_CTL registers
to be reprogrammed using {enable,disable}_all(). However,
PerfMonV2 variants of these functions do not reprogram the
PERF_CTL registers. Hence, the legacy enable_all() function
should also be called.

Fixes: 9622e67e ("perf/x86/amd/core: Add PerfMonV2 counter control")
Reported-by: NLike Xu <likexu@tencent.com>
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20220518084327.464005-1-sandipan.das@amd.com

mainline inclusion
from mainline-v5.19
commit 7685665c
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

If AMD Performance Monitoring Version 2 (PerfMonV2) is
supported, use a new scheme to process Core PMC overflows
in the NMI handler using the new global control and status
registers. This will be bypassed on unsupported hardware
(x86_pmu.version < 2).

In x86_pmu_handle_irq(), overflows are detected by testing
the contents of the PERF_CTR register for each active PMC in
a loop. The new scheme instead inspects the overflow bits of
the global status register.

The Performance Counter Global Status (PerfCntrGlobalStatus)
register has overflow (PerfCntrOvfl) bits for each PMC. This
is, however, a read-only MSR. To acknowledge that overflows
have been processed, the NMI handler must clear the bits by
writing to the PerfCntrGlobalStatusClr register.

In x86_pmu_handle_irq(), PMCs counting the same event that
are started and stopped at the same time record slightly
different counts due to delays in between reads from the
PERF_CTR registers. This is fixed by stopping and starting
the PMCs at the same before and with a single write to the
Performance Counter Global Control (PerfCntrGlobalCtl) upon
entering and before exiting the NMI handler.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/f20b7e4da0b0a83bdbe05857f354146623bc63ab.1650515382.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 9622e67e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

If AMD Performance Monitoring Version 2 (PerfMonV2) is
supported, use a new scheme to manage the Core PMCs using
the new global control and status registers. This will be
bypassed on unsupported hardware (x86_pmu.version < 2).

Currently, all PMCs have dedicated control (PERF_CTL) and
counter (PERF_CTR) registers. For a given PMC, the enable
(En) bit of its PERF_CTL register is used to start or stop
counting.

The Performance Counter Global Control (PerfCntrGlobalCtl)
register has enable (PerfCntrEn) bits for each PMC. For a
PMC to start counting, both PERF_CTL and PerfCntrGlobalCtl
enable bits must be set. If either of those are cleared,
the PMC stops counting.

In x86_pmu_{en,dis}able_all(), the PERF_CTL registers of
all active PMCs are written to in a loop. Ideally, PMCs
counting the same event that were started and stopped at
the same time should record the same counts. Due to delays
in between writes to the PERF_CTL registers across loop
iterations, the PMCs cannot be enabled or disabled at the
same instant and hence, record slightly different counts.
This is fixed by enabling or disabling all active PMCs at
the same time with a single write to the PerfCntrGlobalCtl
register.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/dfe8e934074aaabc6ba748dfaccd0a77c974bb82.1650515382.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 56e026a7
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

If AMD Performance Monitoring Version 2 (PerfMonV2) is
supported, use CPUID leaf 0x80000022 EBX to detect the
number of Core PMCs. This offers more flexibility if the
counts change in later processor families.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/68a6d9688df189267db26530378870edd34f7b06.1650515382.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 21d59e3e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

AMD Performance Monitoring Version 2 (PerfMonV2) introduces
some new Core PMU features such as detection of the number
of available PMCs and managing PMCs using global registers
namely, PerfCntrGlobalCtl and PerfCntrGlobalStatus.

Clearing PerfCntrGlobalCtl and PerfCntrGlobalStatus ensures
that all PMCs are inactive and have no pending overflows
when CPUs are onlined or offlined.

The PMU version (x86_pmu.version) now indicates PerfMonV2
support and will be used to bypass the new features on
unsupported processors.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/dc8672ecbddff394e088ca8abf94b089b8ecc2e7.1650515382.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 089be16d
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add MSR definitions that will be used to enable the new AMD
Performance Monitoring Version 2 (PerfMonV2) features. These
include:

  * Performance Counter Global Control (PerfCntrGlobalCtl)
  * Performance Counter Global Status (PerfCntrGlobalStatus)
  * Performance Counter Global Status Clear (PerfCntrGlobalStatusClr)

The new Performance Counter Global Control and Status MSRs
provide an interface for enabling or disabling multiple
counters at the same time and for testing overflow without
probing the individual registers for each PMC.

The availability of these registers is indicated through the
PerfMonV2 feature bit of CPUID leaf 0x80000022 EAX.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/cdc0d8f75bd519848731b5c64d924f5a0619a573.1650515382.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit d6d0c7f6
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

CPUID leaf 0x80000022 i.e. ExtPerfMonAndDbg advertises some
new performance monitoring features for AMD processors.

Bit 0 of EAX indicates support for Performance Monitoring
Version 2 (PerfMonV2) features. If found to be set during
PMU initialization, the EBX bits of the same CPUID function
can be used to determine the number of available PMCs for
different PMU types. Additionally, Core PMCs can be managed
using new global control and status registers.

For better utilization of feature words, PerfMonV2 is added
as a scattered feature bit.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/c70e497e22f18e7f05b025bb64ca21cc12b17792.1650515382.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit d5616bac
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

On AMD Fam19h Zen3, the branch sampling (BRS) feature must be disabled before
entering low power and re-enabled (if was active) when returning from low
power. Otherwise, the NMI interrupt may be held up for too long and cause
problems. Stopping BRS will cause the NMI to be delivered if it was held up.

Define a perf_amd_brs_lopwr_cb() callback to stop/restart BRS.  The callback
is protected by a jump label which is enabled only when AMD BRS is detected.
In all other cases, the callback is never called.
Signed-off-by: NStephane Eranian <eranian@google.com>
[peterz: static_call() and build fixes]
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-10-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 2a606a18
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add an optional callback needed by some PMU features, e.g., AMD
BRS, to give a chance to the perf_events code to change its state before
a CPU goes to low power and after it comes back.

The callback is void when the PERF_NEEDS_LOPWR_CB flag is not set.
This flag must be set in arch specific perf_event.h header whenever needed.
When not set, there is no impact on the ACPI code.
Signed-off-by: NStephane Eranian <eranian@google.com>
[peterz: build fix]
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-9-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit cc37e520
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add a kernel config option CONFIG_PERF_EVENTS_AMD_BRS
to make the support for AMD Zen3 Branch Sampling (BRS) an opt-in
compile time option.
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-8-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit ba2fe750
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add code to adjust the sampling event period when used with the Branch
Sampling feature (BRS). Given the depth of the BRS (16), the period is
reduced by that depth such that in the best case scenario, BRS saturates at
the desired sampling period. In practice, though, the processor may execute
more branches. Given a desired period P and a depth D, the kernel programs
the actual period at P - D. After P occurrences of the sampling event, the
counter overflows. It then may take X branches (skid) before the NMI is
caught and held by the hardware and BRS activates. Then, after D branches,
BRS saturates and the NMI is delivered.  With no skid, the effective period
would be (P - D) + D = P. In practice, however, it will likely be (P - D) +
X + D. There is no way to eliminate X or predict X.
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-7-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 8910075d
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

The AMD Branch Sampling features does not provide hardware filtering by
privilege level. The associated PMU counter does but not the branch sampling
by itself. Given how BRS operates there is a possibility that BRS captures
kernel level branches even though the event is programmed to count only at
the user level.

Implement a workaround in software by removing the branches which belong to
the wrong privilege level. The privilege level is evaluated on the target of
the branch and not the source so as to be compatible with other architectures.
As a consequence of this patch, the number of entries in the
PERF_RECORD_BRANCH_STACK buffer may be less than the maximum (16).  It could
even be zero. Another consequence is that consecutive entries in the branch
stack may not reflect actual code path and may have discontinuities, in case
kernel branches were suppressed. But this is no different than what happens
on other architectures.
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-6-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit 44175993
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add a pseudo event called branch-brs to help use the FAM Fam19h
Branch Sampling feature (BRS). BRS samples taken branches, so it is best used
when sampling on a retired taken branch event (0xc4) which is what BRS
captures.  Instead of trying to remember the event code or actual event name,
users can simply do:

$ perf record -b -e cpu/branch-brs/ -c 1000037 .....
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-5-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit ada54345
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add support for the AMD Fam19h 16-deep branch sampling feature as
described in the AMD PPR Fam19h Model 01h Revision B1.  This is a model
specific extension. It is not an architected AMD feature.

The Branch Sampling (BRS) operates with a 16-deep saturating buffer in MSR
registers. There is no branch type filtering. All control flow changes are
captured. BRS relies on specific programming of the core PMU of Fam19h.  In
particular, the following requirements must be met:
 - the sampling period be greater than 16 (BRS depth)
 - the sampling period must use a fixed and not frequency mode

BRS interacts with the NMI interrupt as well. Because enabling BRS is
expensive, it is only activated after P event occurrences, where P is the
desired sampling period.  At P occurrences of the event, the counter
overflows, the CPU catches the interrupt, activates BRS for 16 branches until
it saturates, and then delivers the NMI to the kernel.  Between the overflow
and the time BRS activates more branches may be executed skewing the period.
All along, the sampling event keeps counting. The skid may be attenuated by
reducing the sampling period by 16 (subsequent patch).

BRS is integrated into perf_events seamlessly via the same
PERF_RECORD_BRANCH_STACK sample format. BRS generates perf_branch_entry
records in the sampling buffer. No prediction information is supported. The
branches are stored in reverse order of execution.  The most recent branch is
the first entry in each record.

No modification to the perf tool is necessary.

BRS can be used with any sampling event. However, it is recommended to use
the RETIRED_BRANCH_INSTRUCTIONS event because it matches what the BRS
captures.

$ perf record -b -c 1000037 -e cpu/event=0xc2,name=ret_br_instructions/ test

$ perf report -D
56531696056126 0x193c000 [0x1a8]: PERF_RECORD_SAMPLE(IP, 0x2): 18122/18230: 0x401d24 period: 1000037 addr: 0
... branch stack: nr:16
.....  0: 0000000000401d24 -> 0000000000401d5a 0 cycles      0
.....  1: 0000000000401d5c -> 0000000000401d24 0 cycles      0
.....  2: 0000000000401d22 -> 0000000000401d5c 0 cycles      0
.....  3: 0000000000401d5e -> 0000000000401d22 0 cycles      0
.....  4: 0000000000401d20 -> 0000000000401d5e 0 cycles      0
.....  5: 0000000000401d3e -> 0000000000401d20 0 cycles      0
.....  6: 0000000000401d42 -> 0000000000401d3e 0 cycles      0
.....  7: 0000000000401d3c -> 0000000000401d42 0 cycles      0
.....  8: 0000000000401d44 -> 0000000000401d3c 0 cycles      0
.....  9: 0000000000401d3a -> 0000000000401d44 0 cycles      0
..... 10: 0000000000401d46 -> 0000000000401d3a 0 cycles      0
..... 11: 0000000000401d38 -> 0000000000401d46 0 cycles      0
..... 12: 0000000000401d48 -> 0000000000401d38 0 cycles      0
..... 13: 0000000000401d36 -> 0000000000401d48 0 cycles      0
..... 14: 0000000000401d4a -> 0000000000401d36 0 cycles      0
..... 15: 0000000000401d34 -> 0000000000401d4a 0 cycles      0
 ... thread: test:18230
 ...... dso: test
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-4-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit a77d41ac
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Add a cpu feature for AMD Fam19h Branch Sampling feature as bit
31 of EBX on CPUID leaf function 0x80000008.
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-3-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19
commit bfe4daf8
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Make it simpler to reset all the info fields on the
perf_branch_entry by adding a helper inline function.

The goal is to centralize the initialization to avoid missing
a field in case more are added.
Signed-off-by: NStephane Eranian <eranian@google.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220322221517.2510440-2-eranian@google.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>