On Fri, Feb 09, 2018 at 03:33:40PM +0000, Roger Pau Monné wrote: > I'm sorry, I'm a little foggy today. Does this mean the call to > libxl__xs_path_cleanup is simply not needed in > libxl__initiate_device_generic_remove?
It is, it's an alternative to setting be/state=XenbusStateClosing, when frontend is unresponsive. To let the backend know that frontend is gone, so it can set be/state=XenbusStateClosed. We have various cases (not comprehensive list): - both frontend and backend operational: after setting be/state=XenbusStateClosing backend wait for frontend confirmation and respond with be/state=XenbusStateClosed; then libxl in dom0 remove frontend entries and libxl in backend domain (which may be the same) remove backend entries - unresponsive backend/frontend: after a timeout, force=1 is used to remove frontend entries, instead of just setting be/state=XenbusStateClosing; then wait for be/state=XenbusStateClosed. If that timeout too, remove both frontend and backend entries - backend gone, with this patch: no place for setting/waiting on be/state - go directly to removing frontend entries, without waiting for be/state=XenbusStateClosed (this is the difference vs force=1) Without this patch the end result is similar, both frontend and backend entries are removed, but in case of backend gone: - libxl waits for be/state=XenbusStateClosed (and obviously timeout) - return value from the function signal an error, which for example confuse libvirt - it thinks the device remove failed, so is still there -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
Description: PGP signature
_______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xenproject.org/mailman/listinfo/xen-devel