On 08/08/2013 01:31 PM, Zhanghaoyu (A) wrote: > And, rebuild the kvm-kmod, then re-insmod kvm-intel.ko with ept=0,
I virsh-save the VM, and then virsh-restore the VM, the performance degradation disappeared, and no GFN printed. But, I also made a test on the first bad commit(612819c3c6e67bac8fceaa7cc402f13b1b63f7e4), and applied above patch too, With EPT disabled, as soon as the restoring completed, the GFNs’ flooding is starting, take some examples to show as below, but, after a period of time, only gfn = 240 printed constantly. And some processes restore failed, so the performance cannot be measured.
This is 0xF0000 which is the BIOS. It makes some sense, though I'm not sure why a running OS would poke there.
It can be a useful hint, but please do as Gleb said. Try your kernel (+kvm-kmod) with current QEMU, current kernel with your QEMU, current kernel with current QEMU. Make a table of which kernel/QEMU combos work and which do not. Then we can try to understand if the bug still exists and perhaps get hints about how your vendor could backport the fix.
Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
