This bug has been copied from bug #647367 and has been proposed
to be backported to 6.0 z-stream (EUS).
Tested on in
I also tried on kernel-2.6.32-71.18.1.el6(patch not included)kernel-2.6.32-71.24.1.el6(patch included)&qemu-kvm-0.12.1.2-2.113.el6_0.8.x86_64
Repeat the steps in https://bugzilla.redhat.com/show_bug.cgi?id=642243#c1 100 times
on kernel-2.6.32-71.18.1.el6 ,no kernel panic occurs in the guest ,can NOT reproduce this issue
on kernel-2.6.32-71.24.1.el6 ,no kernel panic occurs in the guest
pls take a look the results above ,I can NOT reproduce on kernel-2.6.32-71.18.1.el6 ,I also tried 100 times on the fixed kernel ,also no kernel panic ,
Based on above ,How to deal with it ?
Confirmed with mst, QE do patch check and regression test to verify this bug:
1. # grep 683781 kernel.spec
- [virt] kvm: write protect memory after slot swap (Michael S. Tsirkin) [683781 647367]
2. Repeat the steps in https://bugzilla.redhat.com/show_bug.cgi?id=642243#c1 100
times on kernel-2.6.32-71.24.1.el6 ,no kernel panic occurs in the guest.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Migrating a guest could have resulted in dirty values for the guest being retained in memory, which could have caused both the guest and qemu to crash. The trigger for this was memory pages being both write-protected and dirty simultaneously. With this update, memory pages in the current bitmap are either dirty or write-protected when migrating a guest, with the result that neither qemu nor guest operating systems crash following a migration.