x86/quirks: Add parameter to clear MSIs early on boot

问题背景：
x86 + Hi1822网卡场景，虚拟机panic后，crash kernel启动生成vmcore过程中，
由于串口中断无法上报，导致1号进程卡住。

原因分析(liangyun):
1. 第二内核启动初始化过程中，init_IRQ 函数预留了0-15 irq的vector(48--63)。 
panic之前，hinic 1822网卡中断恰好也是使用了这部分vector，在panic之后，仍有网卡中断上报，
由于vector恰好与init_IRQ 函数预留的一样，就误走到了handle_level_irq这个处理函数。
如果vector不冲突的情况下，走else分支，会写EOI寄存器。
```
 desc = __this_cpu_read(vector_irq[vector]);
 if (likely(!IS_ERR_OR_NULL(desc))) {
	handle_irq(desc, regs);//误走到handle_level_irq
 } else {
	ack_APIC_irq();//native_apic_msr_eoi_write,写EOI寄存器
	__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
 }
```		
对网卡中断不回应EOI，会导致后续不再上报设备中断。
2. 第二内核启动阶段， apic_pending_intr_clear 函数，其实已经考虑到中断残留，
需要回应EOI的场景，会读取是否有pending的中断，并回复EOI。
参考https://lore.kernel.org/all/20190722105219.158847694@linutronix.de/T/#u
```
for (i = 0; i < 512; i++) {
    if (!apic_check_and_ack(&irr, &isr))//当没有中断pending时，退出循环，否则要执行512次。
	return;
}
```		
但是，存在这种情况，在走完apic_pending_intr_clear函数后，仍有网卡中断上报，
此后就没有人帮忙回EOI了，导致后续设备中断不上报， 无法正常走完kdump流程。

解决方案：
ubuntu社区有类似问题，现象稍不同，但补丁可以解决问题。参考链接如下：
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1797990
https://lore.kernel.org/linux-pci/20181018183721.27467-3-gpiccoli@canonical.com/
https://patchwork.kernel.org/project/linux-pci/patch/20181018183721.27467-3-gpiccoli@canonical.com/
相关补丁已回合ubuntu Xenial, Bionic, Cosmic, Disco release版本。

GVP openEuler / kernel
Closed

Content Risk Flag

Comments (2)

GVPopenEuler / kernelClosed

Content Risk Flag