[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [Qemu-devel] [PATCH] call HotplugHandler->plug() as the
Re: [qemu-s390x] [Qemu-devel] [PATCH] call HotplugHandler->plug() as the last step in device realization
Tue, 16 Oct 2018 15:56:00 +0200
On Tue, 16 Oct 2018 15:33:40 +0200
Igor Mammedov <address@hidden> wrote:
> When  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  proper fix which essentially reverts 
> 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 
> 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/address@hidden/msg549915.html
> Signed-off-by: Igor Mammedov <address@hidden>
> remove usage of Error** from plug() callback, we need to factor out
> pre_plug part from plug() callbacks, before proceeding with it.
> DavidH has recently finished it for pc-dimm/memory_devices, cpus
> mostly have pre_plug parts factored out, but there still are parts
> that could fail so it needs some more work to eliminate failure points
> from plug() callbacks. Meanwhile, I'll plan to treat other misc
> handlers (pci[e]/acpi/usb/...) and introduce pre_plug() where
Forgot to CC spapr/s390 folks to give it an extra scrutiny.
- Re: [qemu-s390x] [Qemu-devel] [PATCH] call HotplugHandler->plug() as the last step in device realization,
Igor Mammedov <=