libxl: fix domain destruction with libxl hotplug script calling
PATCH 1/1 libxl: fix domain destruction with libxl hotplug script calling
When calling hotplug scripts from libxl we have to make sure the device is disconnected before attepmting to execute hotplug scripts.
This patch series sets frontend status to 6 when a domain is destroyed, so the devices are disconnected and then execute hotplug scripts.
Also the syntax of the libxl_domain_destroy has been changed to always force the destruction.
This series should be applied after "libxl: add support for hotplug script calling from libxl".
Please review, Roger.
PATCH 1/1 libxl: set frontend status to 6 on domain destroy
# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1323079583 -3600
# Node ID bc90cfd8dd220d69d09cf94a3d39ff3cef76d021 # Parent 274fa4aea2a30fb82228513f969d7cb807813bb8
libxl: set frontend status to 6 on domain destroy
Set frontend status to 6 on domain destruction and wait for devices to be disconnected before executing hotplug scripts.
tools/libxl/libxl_device.c +1 -4
@@ -513,10 +513,7 @@ int libxl__device_destroy(libxl__gc *gc,char *be_path =libxl__device_backend_path (gc, dev);char *fe_path =libxl__device_frontend_path (gc, dev); -/* -* Run hotplug scripts, which will probably not be able to -* execute successfully since the device may still be plugged -*/ +libxl__xs_write (gc,XBT_NULL ,libxl__sprintf (gc,"%s/%s" , fe_path,"state" ),"6" );libxl__device_execute_hotplug (gc, dev,DISCONNECT );xs_rm (ctx->xsh,XBT_NULL , be_path);
PATCH 1/1 libxl: remove force parameter from libxl_domain_destroy
In reply to Roger Pau Monne# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1323079605 -3600
# Node ID c0d51df66b829995c4eb3902b5b9914c710a6c01 # Parent bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter from libxl_domain_destroy
Since a destroy is considered a forced shutdown, there's no point in passing a force parameter. All the occurences of this function have been replaced with the proper syntax.
tools/libxl/libxl.c +2 -2
@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libxreturn 1 ; } -int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid,int force) +int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid) {libxl__gc gc =LIBXL_INIT_GC (ctx);libxl_dominfo dominfo;
@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,libxl__qmp_cleanup (&gc, domid); } -if (libxl__devices_destroy (&gc, domid, force) <0 ) +if (libxl__devices_destroy (&gc, domid,1 ) <0 )LIBXL__LOG (ctx,LIBXL__LOG_ERROR ,"libxl__devices_destroy failed for %d" , domid); vm_path =libxl__xs_read (&gc,XBT_NULL ,libxl__sprintf (&gc,"%s/vm" , dom_path));
tools/libxl/libxl.h +1 -1
@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd);int libxl_domain_resume (libxl_ctx *ctx,uint32_t domid);int libxl_domain_shutdown (libxl_ctx *ctx,uint32_t domid,int req); -int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid,int force); +int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid);int libxl_domain_preserve (libxl_ctx *ctx,uint32_t domid,libxl_domain_create_info *info,const char *name_suffix,libxl_uuid new_uuid);/* get max. number of cpus supported by hypervisor */
tools/libxl/libxl_create.c +1 -1
@@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g error_out:if (domid) -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid);return ret; }
tools/libxl/libxl_dm.c +1 -1
@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g goto out; }LIBXL__LOG (ctx,LIBXL__LOG_DEBUG ,"Device model is a stubdom, domid=%d" , stubdomid); - ret =libxl_domain_destroy (ctx, stubdomid,0 ); + ret =libxl_domain_destroy (ctx, stubdomid);if (ret) goto out; }else {
tools/libxl/xl_cmdimpl.c +6 -6
@@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx/* fall-through */ case LIBXL_ACTION_ON_SHUTDOWN_DESTROY :LOG ("Domain %d needs to be cleaned up: destroying the domain" , domid); -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid);break ;case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY :
@@ -1698,7 +1698,7 @@ start: error_out:release_lock ();if (libxl_domid_valid_guest (domid)) -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid); out:if (logfile !=2 )
@@ -2168,7 +2168,7 @@ static void destroy_domain(const char *pfprintf (stderr,"Cannot destroy privileged domain 0.\n\n" );exit (-1 ); } - rc =libxl_domain_destroy (ctx, domid,0 ); + rc =libxl_domain_destroy (ctx, domid);if (rc) {fprintf (stderr,"destroy failed (rc=%d)\n" ,rc);exit (-1 ); } }
@@ -2414,7 +2414,7 @@ static int save_domain(const char *p, coif (checkpoint)libxl_domain_unpause (ctx, domid);else -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid);exit (0 ); }
@@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d }fprintf (stderr,"migration sender: Target reports successful startup.\n" ); -libxl_domain_destroy (ctx, domid,1 );/* bang! */ +libxl_domain_destroy (ctx, domid);/* bang! */ fprintf (stderr,"Migration successful.\n" );exit (0 );
@@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, iif (rc) {fprintf (stderr,"migration target: Failure, destroying our copy.\n" ); - rc2 =libxl_domain_destroy (ctx, domid,1 ); + rc2 =libxl_domain_destroy (ctx, domid);if (rc2) {fprintf (stderr,"migration target: Failed to destroy our copy" " (code %d).\n" , rc2);
tools/python/xen/lowlevel/xl/xl.c +3 -3
@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xlstatic PyObject *pyxl_domain_destroy (XlObject *self,PyObject *args) { -int domid, force =1 ; -if ( !PyArg_ParseTuple (args,"i|i" , &domid, &force) ) +int domid; +if ( !PyArg_ParseTuple (args,"i" , &domid) )return NULL ; -if (libxl_domain_destroy (self->ctx, domid, force) ) { +if (libxl_domain_destroy (self->ctx, domid) ) {PyErr_SetString (xl_error_obj,"cannot destroy domain" );return NULL ; }
Re: [PATCH 2 of 2] libxl: remove force parameter from libxl_domain_destroy
Did patch 1/2 get stuck somewhere? I've not seen it yet.
Quoted 10 lines · Roger Pau Monne
# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1323079605 -3600
# Node IDc0d51df66b829995c4eb3902b5b9914c710a6c01# Parentbc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter fromlibxl_domain_destroySince a destroy is considered a forced shutdown, there's no point in passing a force parameter. All the occurences of this function have been replaced with the proper syntax.
I'm a little concerned with the change in libxl__destroy_device_model, mostly because I don';t know what the expected semantics of a stub dom shutdown are. Perhaps it is fine to shoot such a domain in the head without previously giving an opportunity to shutdown?
Quoted 16 lines
Signed-off-by Roger Pau Monne <[email protected]>diff -r
bc90cfd8dd22-rc0d51df66b82tools/libxl/libxl.ctools/libxl/libxl.c +1
-1@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libxreturn 1 ; } -int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid,int force) +int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid) {libxl__gc gc =LIBXL_INIT_GC (ctx);libxl_dominfo dominfo;
tools/libxl/libxl.c int libxl_domain_destroy(libxl_ctx *ctx, · line 770
Quoted 5 lines
tools/libxl/libxl.c +1
-1@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,libxl__qmp_cleanup (&gc, domid); } -if (libxl__devices_destroy (&gc, domid, force) <0 ) +if (libxl__devices_destroy (&gc, domid,1 ) <0 )
If I'm not missing something this seems to be the only caller of libxl__device_destroy. We could keep pushing this change down and remove the force param here too which in turns removes a bunch of code from libxl__devices_destroy and makes it behave like its name suggests.
Quoted 118 lines
tools/libxl/libxl.c +0
-0LIBXL__LOG (ctx,LIBXL__LOG_ERROR ,"libxl__devices_destroy failed for %d" , domid); vm_path =libxl__xs_read (&gc,XBT_NULL ,libxl__sprintf (&gc,"%s/vm" , dom_path));diff -r
bc90cfd8dd22-rc0d51df66b82tools/libxl/libxl.htools/libxl/libxl.h +1
-1@@ -269,7 +269,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd);int libxl_domain_resume (libxl_ctx *ctx,uint32_t domid);int libxl_domain_shutdown (libxl_ctx *ctx,uint32_t domid,int req); -int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid,int force); +int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid);int libxl_domain_preserve (libxl_ctx *ctx,uint32_t domid,libxl_domain_create_info *info,const char *name_suffix,libxl_uuid new_uuid);/* get max. number of cpus supported by hypervisor */ diff -r
bc90cfd8dd22-rc0d51df66b82tools/libxl/libxl_create.ctools/libxl/libxl_create.c +1
-1@@ -646,7 +646,7 @@ static int do_domain_create(libxl__gc *g error_out:if (domid) -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid);return ret; }diff -r
bc90cfd8dd22-rc0d51df66b82tools/libxl/libxl_dm.ctools/libxl/libxl_dm.c +1
-1@@ -917,7 +917,7 @@ int libxl__destroy_device_model(libxl__g goto out; }LIBXL__LOG (ctx,LIBXL__LOG_DEBUG ,"Device model is a stubdom, domid=%d" , stubdomid); - ret =libxl_domain_destroy (ctx, stubdomid,0 ); + ret =libxl_domain_destroy (ctx, stubdomid);if (ret) goto out; }else {diff -r
bc90cfd8dd22-rc0d51df66b82tools/libxl/xl_cmdimpl.ctools/libxl/xl_cmdimpl.c +6
-6@@ -1200,7 +1200,7 @@ static int handle_domain_death(libxl_ctx/* fall-through */ case LIBXL_ACTION_ON_SHUTDOWN_DESTROY :LOG ("Domain %d needs to be cleaned up: destroying the domain" , domid); -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid);break ;case LIBXL_ACTION_ON_SHUTDOWN_COREDUMP_DESTROY :@@ -1698,7 +1698,7 @@ start: error_out:release_lock ();if (libxl_domid_valid_guest (domid)) -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid); out:if (logfile !=2 )@@ -2168,7 +2168,7 @@ static void destroy_domain(const char *pfprintf (stderr,"Cannot destroy privileged domain 0.\n\n" );exit (-1 ); } - rc =libxl_domain_destroy (ctx, domid,0 ); + rc =libxl_domain_destroy (ctx, domid);if (rc) {fprintf (stderr,"destroy failed (rc=%d)\n" ,rc);exit (-1 ); } }@@ -2414,7 +2414,7 @@ static int save_domain(const char *p, coif (checkpoint)libxl_domain_unpause (ctx, domid);else -libxl_domain_destroy (ctx, domid,0 ); +libxl_domain_destroy (ctx, domid);exit (0 ); }@@ -2647,7 +2647,7 @@ static void migrate_domain(const char *d }fprintf (stderr,"migration sender: Target reports successful startup.\n" ); -libxl_domain_destroy (ctx, domid,1 );/* bang! */ +libxl_domain_destroy (ctx, domid);/* bang! */ fprintf (stderr,"Migration successful.\n" );exit (0 );@@ -2764,7 +2764,7 @@ static void migrate_receive(int debug, iif (rc) {fprintf (stderr,"migration target: Failure, destroying our copy.\n" ); - rc2 =libxl_domain_destroy (ctx, domid,1 ); + rc2 =libxl_domain_destroy (ctx, domid);if (rc2) {fprintf (stderr,"migration target: Failed to destroy our copy" " (code %d).\n" , rc2);diff -r
bc90cfd8dd22-rc0d51df66b82tools/python/xen/lowlevel/xl/xl.ctools/python/xen/lowlevel/xl/xl.c +3
-3@@ -437,10 +437,10 @@ static PyObject *pyxl_domain_shutdown(Xlstatic PyObject *pyxl_domain_destroy (XlObject *self,PyObject *args) { -int domid, force =1 ; -if ( !PyArg_ParseTuple (args,"i|i" , &domid, &force) ) +int domid; +if ( !PyArg_ParseTuple (args,"i" , &domid) )return NULL ; -if (libxl_domain_destroy (self->ctx, domid, force) ) { +if (libxl_domain_destroy (self->ctx, domid) ) {PyErr_SetString (xl_error_obj,"cannot destroy domain" );return NULL ; }_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Re: [PATCH 2 of 2] libxl: remove force parameter from libxl_domain_destroy
Quoted 1 line · Ian Campbell
Did patch 1/2 get stuck somewhere? I've not seen it yet.
NM. Got it now, thanks.
Re: [PATCH 2 of 2] libxl: remove force parameter from libxl_domain_destroy
In reply to Ian Campbell2011/12/5 Ian Campbell <[email protected]>:
Quoted 10 lines
Did patch 1/2 get stuck somewhere? I've not seen it yet.
Quoted 7 lines · Roger Pau Monne
# HG changeset patch
# User Roger Pau Monne <[email protected]> # Date 1323079605 -3600
# Node IDc0d51df66b829995c4eb3902b5b9914c710a6c01# Parent bc90cfd8dd220d69d09cf94a3d39ff3cef76d021
libxl: remove force parameter fromlibxl_domain_destroy
Quoted 8 lines
Quoted 3 lines
Since a destroy is considered a forced shutdown, there's no point in passing a force parameter. All the occurences of this function have been replaced with the proper syntax.
I'm a little concerned with the change in
libxl__destroy_device_model, mostly because I don';t know what the expected semantics of a stub dom shutdown are. Perhaps it is fine to shoot such a domain in the head without previously giving an opportunity to shutdown?
I'm sorry, but I don't know about stubdoms, they are not working under NetBSD *yet*, I will probably get with this once I finish porting libxl (or a userspace blktap implementation, that's also quite outstanding).
Quoted 17 lines
Quoted 17 lines
Signed-off-by Roger Pau Monne <[email protected]>diff -r
bc90cfd8dd22-rc0d51df66b82tools/libxl/libxl.ctools/libxl/libxl.c Mon Dec 05 11:06:45 2011 +0100 renamed from tools/libxl/libxl.c Mon Dec 05 11:06:23 2011 +0100 +1
-1@@ -718,7 +718,7 @@ int libxl_event_get_disk_eject_info(libx return 1; } -int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid, int force) +int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid) { libxl__gc gc = LIBXL_INIT_GC(ctx); libxl_dominfo dominfo;@@ -767,7 +767,7 @@ int libxl_domain_destroy(libxl_ctx *ctx,
Quoted 9 lines
tools/libxl/libxl.c Mon Dec 05 11:06:45 2011 +0100 int libxl_domain_destroy(libxl_ctx *ctx, · line 770
Quoted 4 lines
tools/libxl/libxl.c Mon Dec 05 11:06:45 2011 +0100 renamed from tools/libxl/libxl.c Mon Dec 05 11:06:23 2011 +0100 +1
-1libxl__qmp_cleanup(&gc, domid); } - if (libxl__devices_destroy(&gc, domid, force) < 0) + if (libxl__devices_destroy(&gc, domid, 1) < 0)If I'm not missing something this seems to be the only caller of
libxl__device_destroy. We could keep pushing this change down and remove the force param here too which in turns removes a bunch of code fromlibxl__devices_destroyand makes it behave like its name suggests.
I've already created another patch that changes the semantics of libxl__device_destroy and removes the force flag and all the unnecessary code. If no one has an objection about this change I will resend the series later with this patch.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel