the win2008r2 vm crash problem while migration seems related about the AllocatePage.
according to the previous BSOD info, we modified code to test if page address after AllocatePage is FFFFFA8000000000 or FFFFFA8000000002. if FFFFFA8000000000 , then free it immediately, and allocate again.
the test result shows
12948535073500: XenPCI --- AllocatePages IRQL = 0, Buf = FFFFFA8000000000
12948535073500: XenPCI XEN_INIT_TYPE_RING - tx-ring-ref = FFFFFA8000000000
12948535073500: XenPCI test - tx-ring-ref = 18446738026395598848
12948535073515: XenPCI --- FreePages IRQL = 0, Buf = FFFFFA8000000000
12948535073515: XenPCI FreePages 1
12948535073515: XenPCI FreePages 2
Log-dirty command enable
Log-dirty command disable
XenPCI Bug check 0x000000C2 (0x0000000000000042, 0xFFFFFA8000000000, 0x0000000000000000, 0x0000000000000000)
reset requested in cpu_handle_ioreq.
Issued domain 1436 reboot
the previous test result without no modification of code is vm crashed, BSOD is also 0x000000C2.
it means when it call ExAllocatePoolWithTag in AllocatePage func, the return address is already wrong.
is this the bug of win2008r2, even pactched with sp1?
And the curious thing is why it always happened in vif allocate ? sometimes tx-ring-ref, sometimes rx-ring-ref
maybe, later, we can do some test about allocate,free in win2008r2sp1 image without pv.
Xen-devel mailing list