Am 29.09.2017 um 05:20 hat wangjie (P) geschrieben: > Excuse me, I have two issues to discuss with you :>
Please don't break the email threading. Make sure that your replies appear in the same thread as the message you're replying to. > //Question 1: > > Can we fix it by the demo patch as attachment? (the patch is base on > qemu-2.8.1, just a demo for discuss) > > Because I think we should not set INACTIVE label for drive-mirror > BlockDriverState, mirror IO will not affect the memory migration. So > we can filter the drive-mirror bs in bdrv_inactivate_all, and I > tested, my demo patch can fix it. No, this is wrong. Images must be inactivated before the destination can continue, so just not inactivating them at all is not the solution. Your patch probably breaks migration with shared storage. It is also wrong from a design perspective because you're fixing a special case of a special case of the bug by introducing a layering violation. So even if not inactivating the images were right, this patch would still be bad. > //Question 2: > > I used git-bisect and found the qemu-2.6.0 is OK, because I cann't > trigger the bug on qemu-2.6.0 even though I tried many times. But > I can trigger the bug and reproduce it very easy since > qemu-2.7.0-rc0. so I git-biset it go on, and found the bug begin to > occur since the patchs committed as following: > > commit cbd614870fce00f46088be7054a7bf5eadcc77ac > Merge: 500acc9 0bc7a6f > Author: Peter Maydell <[email protected]> > Date: Thu Jun 2 13:42:52 2016 +0100 > > Merge remote-tracking branch 'remotes/famz/tags/pull-docker-20160601' > into staging This looks rather unlikely to be the real culprit, especially because it's only a merge commit. Kevin
