aboutsummaryrefslogtreecommitdiff
path: root/exec.c
diff options
context:
space:
mode:
authorIgor Mammedov <imammedo@redhat.com>2018-10-16 15:33:40 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2018-10-19 13:44:12 +0200
commit8b5e6caf01f778a257721cae499392e8f1d55ddb (patch)
tree6a759622e34ac8b78c21a50759fb66a49bd79318 /exec.c
parentac0989f53dd08ba7831130396f794b3e3bdf2d1a (diff)
call HotplugHandler->plug() as the last step in device realization
When [2] was fixed it was agreed that adding and calling post_plug() callback after device_reset() was low risk approach to hotfix issue right before release. So it was merged instead of moving already existing plug() callback after device_reset() is called which would be more risky and require all plug() callbacks audit. Looking at the current plug() callbacks, it doesn't seem that moving plug() callback after device_reset() is breaking anything, so here goes agreed upon [3] proper fix which essentially reverts [1][2] and moves plug() callback after device_reset(). This way devices always comes to plug() stage, after it's been fully initialized (including being reset), which fixes race condition [2] without need for an extra post_plug() callback. 1. (25e897881 "qdev: add HotplugHandler->post_plug() callback") 2. (8449bcf94 "virtio-scsi: fix hotplug ->reset() vs event race") 3. https://www.mail-archive.com/qemu-devel@nongnu.org/msg549915.html Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1539696820-273275-1-git-send-email-imammedo@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Pierre Morel<pmorel@linux.ibm.com> Acked-by: Pierre Morel<pmorel@linux.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'exec.c')
0 files changed, 0 insertions, 0 deletions