Xen devel - May 2007 - [PATCH] Fix xm save timeout with paused domains

# HG changeset patch
# User john.levon@sun.com
# Date 1178640308 25200
# Node ID eee26efa7fad6ff7ba9ab43dfec82995e9df4653
# Parent  62709adfbeec35215e97f7dbe0ab64c704fca26d
Fix xm save timeout with paused domains.

Don''t start migrating a domU before it''s unpaused.

Signed-off-by: Max Zhen <max.zhen@sun.com>

diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -454,14 +454,26 @@ static void *map_frame_list_list(int xc_
                                  shared_info_t *shinfo)
 {
     int count = 100;
+    int paused = 1;
+    xc_dominfo_t info;
     void *p;
 
-    while ( count-- && (shinfo->arch.pfn_to_mfn_frame_list_list ==
0) )
+    while ( count && (shinfo->arch.pfn_to_mfn_frame_list_list == 0)
)
+    {
+        if (paused && xc_domain_getinfo(xc_handle, dom, 1, &info)
!= 1)
+        {
+            ERROR("Could not get domain info");
+            return NULL;
+        }
+        paused = info.paused;
+        if (!paused)
+            count--; /* start the counter only after dom is unpaused */
         usleep(10000);
+    }
 
     if ( shinfo->arch.pfn_to_mfn_frame_list_list == 0 )
     {
-        ERROR("Timed out waiting for frame list updated.");
+        ERROR("Timed out waiting for frame list update.");
         return NULL;
     }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

How about just not pausing a domain that you''re going to save?

 -- Keir

On 8/5/07 17:05, "john.levon@sun.com" <john.levon@sun.com>
wrote:
> # HG changeset patch
> # User john.levon@sun.com
> # Date 1178640308 25200
> # Node ID eee26efa7fad6ff7ba9ab43dfec82995e9df4653
> # Parent  62709adfbeec35215e97f7dbe0ab64c704fca26d
> Fix xm save timeout with paused domains.
> 
> Don''t start migrating a domU before it''s unpaused.
> 
> Signed-off-by: Max Zhen <max.zhen@sun.com>
> 
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -454,14 +454,26 @@ static void *map_frame_list_list(int xc_
>                                   shared_info_t *shinfo)
>  {
>      int count = 100;
> +    int paused = 1;
> +    xc_dominfo_t info;
>      void *p;
>  
> -    while ( count-- && (shinfo->arch.pfn_to_mfn_frame_list_list
== 0) )
> +    while ( count && (shinfo->arch.pfn_to_mfn_frame_list_list
== 0) )
> +    {
> +        if (paused && xc_domain_getinfo(xc_handle, dom, 1,
&info) != 1)
> +        {
> +            ERROR("Could not get domain info");
> +            return NULL;
> +        }
> +        paused = info.paused;
> +        if (!paused)
> +            count--; /* start the counter only after dom is unpaused */
>          usleep(10000);
> +    }
>  
>      if ( shinfo->arch.pfn_to_mfn_frame_list_list == 0 )
>      {
> -        ERROR("Timed out waiting for frame list updated.");
> +        ERROR("Timed out waiting for frame list update.");
>          return NULL;
>      }
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, May 08, 2007 at 05:15:42PM +0100, Keir Fraser wrote:
> How about just not pausing a domain that you''re going to save?
This doesn''t work when you''re doing tight save/restore /
migration
loops, where the unpausing happens after plugging virtual devices for
the new domain. This can cause the timer to expire before we unpause the
domain and give it a chance to update its frame list entry.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/5/07 17:25, "John Levon" <levon@movementarian.org> wrote:
>> How about just not pausing a domain that you''re going to save?
> 
> This doesn''t work when you''re doing tight save/restore /
migration
> loops, where the unpausing happens after plugging virtual devices for
> the new domain. This can cause the timer to expire before we unpause the
> domain and give it a chance to update its frame list entry.
Hmm.. Perhaps ''xm restore/migrate'' shouldn''t return
until the new domain is
actually running. Or (probably easier) xend should hold save requests
pending until the domain concerned is unpaused?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, May 08, 2007 at 05:26:50PM +0100, Keir Fraser wrote:
> >> How about just not pausing a domain that you''re going to
save?
> > 
> > This doesn''t work when you''re doing tight
save/restore / migration
> > loops, where the unpausing happens after plugging virtual devices for
> > the new domain. This can cause the timer to expire before we unpause
the
> > domain and give it a chance to update its frame list entry.
> 
> Hmm.. Perhaps ''xm restore/migrate'' shouldn''t
return until the new domain is
> actually running.
This wouldn''t protect against requests via the Xen API.
> Or (probably easier) xend should hold save requests pending until the
> domain concerned is unpaused?
If you''d prefer it there, that''s probably possible too.

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/5/07 17:37, "John Levon" <levon@movementarian.org> wrote:
>> Hmm.. Perhaps ''xm restore/migrate'' shouldn''t
return until the new domain is
>> actually running.
> This wouldn''t protect against requests via the Xen API.
Yeah, this probably isn''t the right place to do this.
>> Or (probably easier) xend should hold save requests pending until the
>> domain concerned is unpaused?
> If you''d prefer it there, that''s probably possible too.
I think xend is the obvious place to implement this type of synchronisation.
The only question is how hard it will be to add in. I can certainly
understand the temptation to hack things into libxc.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, May 08, 2007 at 05:38:50PM +0100, Keir Fraser wrote:
> I think xend is the obvious place to implement this type of
synchronisation.
I think I agree. It would be easy if we were to just loop until the
domain gets unpaused but that''s not really quite the correct fix, since
we ideally want ''xm save'' to fail cleanly if the domain is
paused (I
vaguely remember seeing a patch for this go past?).
> The only question is how hard it will be to add in.
Maybe a xenstore entry for the domain which is written just after the
.unpause() (the absence of this would also prevent xm pause, xm destroy,
perhaps)

regards
john

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/5/07 18:14, "John Levon" <levon@movementarian.org> wrote:
>> I think xend is the obvious place to implement this type of
synchronisation.
> 
> I think I agree. It would be easy if we were to just loop until the
> domain gets unpaused but that''s not really quite the correct fix,
since
> we ideally want ''xm save'' to fail cleanly if the domain
is paused (I
> vaguely remember seeing a patch for this go past?).
> 
>> The only question is how hard it will be to add in.
> 
> Maybe a xenstore entry for the domain which is written just after the
> .unpause() (the absence of this would also prevent xm pause, xm destroy,
> perhaps)
Yes, some kind of state field in xenstore to aid synchronisation
wouldn''t be
a bad idea. It could be set to various states depending on whether a domain
is starting, xm-paused, being saved, etc. and operation can sync on that
field by waiting for it to switch to ''running''.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel