【openeuler 4.19】构造oom后，对端虚拟机卡死，无法登录

x86在跳转到第二内核时，reboot IPI可能处于pending状态然后在第二内核中被响应，stopping_cpu只有在正常reboot流程中才会被置位如果是-1表示可以忽略reboot IPI

```
X86虚拟机对CPU0进reboot操作                             同时在CPU2上故障注入Panic，内核进入kdump流程 
local_irq_disable                                       kernel_kexec
send reboot IPI                                         local_irq_disable
                                                        send reboot IPI 给cpu0，但失败
                                                        send NMI 给 CPU0
CPU0 收到 NMI 后 Halt
                                                        lapci soft disable
                                                        Irq_init and Then handle IPI
                                                        处理 CPU0 发来的 IPI 后 Halt, IPI Context
```

在x86 reboot ipi handler： sysvec_reboot 中直接判断 stopping_cpu 是否被赋值，stopping_cpu 存储的是正在被停止的 CPU 编号，-1即所有CPU都在线
只有在 stopping_cpu！= -1 的场景下才会发送 reboot ipi，否则可以直接不处理当前ipi
**二、缺陷分析结构反馈**
影响性分析说明：

缺陷严重等级:(Critical/High/Moderate/Low)

缺陷根因说明:

受影响版本排查(受影响/不受影响):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1
openEuler-24.03-LTS-SP2

修复是否涉及abi变化(是/否):
openEuler-20.03-LTS-SP4
openEuler-22.03-LTS-SP3
openEuler-22.03-LTS-SP4
openEuler-24.03-LTS
openEuler-24.03-LTS-SP1
openEuler-24.03-LTS-SP2

GVP openEuler / kernel
Closed

Content Risk Flag

Comments (3)

GVPopenEuler / kernelClosed

Content Risk Flag