Re: [Xen-devel] [PATCH] libxl: do not fail device removal if backend domain is gone

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.pau@xxxxxxxxxx>

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel