[linux][qemu]PVPanic的缺陷和完善

前言

前文《[linux][qemu]PVPanic的实现原理以及应用》中，介绍了pvpanic的原理和基本的使用方法，KVM虚拟化场景下，使用pvpanic驱动可以监控到Guest的panic。

但是实际的应用场景中，pvpanic实际上和kdump工具冲突。下面我们来分析一下为什么冲突，以及如何解决。

分析

pvpanic和kdump为什么冲突

在配置了kdump的情况下，panic发生之后，内核会尝试加载新的内核，根据配置参数dump内存到磁盘中。那么，也就不会调用pvpanic注册的callback函数，从而导致pvpanic没法收到通知。

如果配置crash_kexec_post_notifiers，那么guest发生了kernel panic之后，会调用pvpanic的callback函数，就会写io port 0x505（默认地址），qemu监控到之后，qemu停止虚拟机 ，并向libvirt进行post消息，我们可以得到通知。那么，guest内部的kdump得不到运行。

所以，kdump和pvpanic不能够同时生效运行。引入的另外一个问题是，配置了kdump之后，发生了panic的话，guest内部发生重启，而我们无法区分是guest内部的正常重启还是kdump重启，会给我们的监控带来很大的困难。

解决办法

我们希望这样的逻辑：

1,如果guest希望自己handle住panic，那么我们只要接收pvpanic的通知即可，让guest继续运行。我们监控到这次guest panic就足够了。

2,如果guest自己不能handle住panic，那么就让qemu甚至上层的软件继续处理。

所以，解决办法就是在pvpanic中增加新的逻辑：

如果没有加载kexec crash loaded，那么写原来的BIT 0。如果加载了kexec crash loaded，那么写新定义的BIT 1。

在qemu侧，对于pvpanic设备的BIT 0操作，还是维持原来的逻辑。对于BIT 1的操作，则post消息给libvirt，然后虚拟机可以继续执行。

在libvirt侧，适配新的消息。更高层次的软件可以适配libvirt新的事件。这样，兼容了原有的逻辑，也可以解决上述的kdump和pvpanic冲突的问题。

在完整功能的upstream过程中，得到了Paolo的支持，感谢Paolo。

patch列表

Linux

e0b9a42735f2672ca2764cfbea6e55a81098d5ba

191941692a3d1b6a9614502b279be062926b70f5

QEMU

600d7b47e8f5085919fd1d1157f25950ea8dbc11

7dc58deea79a343ac3adc5cadb97215086054c86

Libvirt

26badd13e8f1931a9a03e3b1ca0620bb0063b856