On Fri, Feb 09, 2018 at 05:32:47PM +0100, Marek Marczykowski-Górecki wrote: > 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
Thanks. I think I've got it now and I agree on the patch. However it might be nice to add the above explanation to the commit message. Reviewed-by: Roger Pau Monné <roger....@citrix.com> Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel