From mboxrd@z Thu Jan 1 00:00:00 1970 From: "James Song" Subject: =?GB2312?Q?Re=A3=BA=20RE:=20Re=A3=BA=20Re:=20=20when?= =?GB2312?Q?=20timer=20go=20back=20in=20dom0=20save=20and=20restore=20orm?= =?GB2312?Q?igrate,=20PV=20domain=20hung?= Date: Wed, 26 Nov 2008 22:10:06 -0700 Message-ID: <492EC65F0200002000007EF2@lucius.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1335942090==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: keir.fraser@eu.citrix.com, kevin.tian@intel.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1335942090== Content-Type: multipart/alternative; boundary="=__Part9AB2F0BE.2__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part9AB2F0BE.2__= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable F.Y.I >>> "Tian, Kevin" 08.11.27. 11:50 >>>Sorry for a typo. I did mean domU instead of dom0. :-) The point here is that time_resume will sync to new system time and wall clock at restore, and thus pv guest should be able to continue... Xen system time is not wallclock time which just counts up from power up. As Keir points out, only its progress is used to drive internal jiffies. --- Actually, save/restore or migrate will not call time_resume, this function mybe only be called in power saving. Then what do you mean for "system time stop" here? TOD at user level, or within kernel you observe xen system time never changing? --- If you run command "date" in user mode, you will find the date of output never change until a time interval equal to the value of time delay. And also, you can run some applicatin without many relation with time. such as vi,cd...etc, but if you run ping x.x.x.x you will find only one line's respose and never go on.=20 Thanks --James From: James Song [mailto:jsong@novell.com] =20 Sent: Thursday, November 27, 2008 11:20 AM To: keir.fraser@eu.citrix.com; Tian, Kevin; =20 xen-devel@lists.xensource.com Subject: =B4=F0=B8=B4=A3=BA Re: [Xen-devel] when timer go back in dom0 = save and restore ormigrate, PV domain hung =20 Hi, yes, there is a patch before to fix problem wc_sec/wc_nsec in xc_domain_restore.c, but it still missed something. If constucting dom0 or restoring of a PV dom. Guest os will read the local wc_sec from xen as it base time.wc_sec is initialized with CMOS =20 data. There were some case which wc_sec will be changed. One is that go back dom0's system-time will change dom0's time and wc_sec smaller which is both Guest os and Xen. Actually, we can do a simple test, starting a pv domain, then change dom0's time, and you will find the system time of guest os stopped. That because you change wc_sec of both xen and guest os. =20 This patch only consider the case of save/restore. I still not sure the policy of this case that is when dom0's system-time go back. what VMs should do? So, I have add this case to this patch By the way, Kevin, Guest OS will hang not dom0 ;-) and also the time of hang just is equivlant to the time interval you go back in =20 dom0 or new machine you migrate. Thanks -- James >>> Keir Fraser 08?11?26? ?? 22:58 >>> So what happens if someone changes wallclock using 'date'? That's basically kind of what will appear to happen when s/r occurs. -- Keir On 26/11/08 14:32, "Tian, Kevin" wrote: hrtimer supports two timer bases: CLOCK_MONOTONIC and =20 CLOCK_REALTIME. wall_to_monotonic is only added in former case, and for=20 latter instead TOD is used directly per my reading. I did a quick search, and it looks that futex and ntp are using CLOCK_REALTIME. Also there's one vsyscall gate which can pass CLOCK_REALTIME from caller too. Thanks, Kevin =20 =20 mailto:keir.fraser@eu.citrix.com] =20 Sent: Wednesday, November 26, 2008 10:26 PM To: Tian, Kevin; 'James Song'; =20 xen-devel@lists.xensource.com Subject: Re: [Xen-devel] when timer go back in dom0 save and restore or migrate, PV domain hung =20 hrtimers add wall_to_monotonic to xtime to get a timesource that doesn't (or shouldn't!) warp. -- Keir On 26/11/08 14:20, "Tian, Kevin" =20 wrote: =20 how about hrtimers? one mode is CLOCK_REALTIME, which uses =20 getnstimeofday as expiration. Once system time is changed either =20 in local or new machine, that expiration can't be adjusted. but =20 i'm not sure whether it still makes sense to try hrtimers in a =20 guest. Thanks Kevin =20 =20 =20 =20 mailto:keir.fraser@eu.citrix.com] =20 Sent: Wednesday, November 26, 2008 10:11 PM To: Tian, Kevin; 'James Song'; =20 xen-devel@lists.xensource.com Subject: Re: [Xen-devel] when timer go back in dom0 save and restore or migrate, PV domain hung =20 The problem hasn't been fully explained, but I can say that PV guests expect system time to jump across s/r and deal with that. For example, Linux doesn't use Xen system time internally, but uses its progress to periodically update jiffies, which does not warp across s/r. We have had problems corrupting wc_sec/wc_nsec in=20 xc_domain_restore.c, but that was fixed some time ago. -- Keir On 26/11/08 14:00, "Tian, Kevin" =20 wrote: =20 =20 This is not a s/r or lm specific issue. For example, =20 system time can be changed even when pv guest is =20 running. Your patch only hacks restore point once, and =20 wc_sec can still be changed later when system time is =20 changed on-the-fly again. IIRC, pv guest can catch up wall clock change in timer=20 interrupt, and time_resume will sync internal processed system time with new system time after restored. But I'm not sure whether it's enough. Actually the more=20 interesting is the uptime difference. For example, timer with expiration calculated on previous system time may wait nearly infinite if uptime among two boxes vary a lot. But I think such issue should have been considered =20 already, e.g. some user tool assistance. I think Keir can comment better here. BTW, do you happen to know what exactly dom0 hangs on? In=20 some busy loop to catch up time, or long delay to some critical timer expiration? Thanks, Kevin =20 =20 =20 =20 =20 =20 mailto:xen-devel-bounces@lists.xensource.com] =20 On Behalf Of James Song Sent: Tuesday, November 25, 2008 4:02 PM To: xen-devel@lists.xensource.com Subject: [Xen-devel] when timer go back in dom0 save and restore or migrate, PV domain hung =20 Hi, I find PV domin hung, When we take those steps =20 =20 1, save PV domain =20 2, change system time of PV domain back =20 =20 3, restore a PV domain =20 or =20 1, migrate a PV domain from Machine A to Machine B 2, the system time of Machine B is slower than Machine A. the problem is wc_sec will be change when system-time chanaged in dom0 or restore in a =20 slower-system-time machine, but when restoring, xen don't restore the wc_sec of share_info from xenstore and use native one. So guest os will hang. =20 this patch will work for this issue. Thanks -- Song Wei diff -r a5ed0dbc829f tools/libxc/xc_domain_restore.c --- a/tools/libxc/xc_domain_restore.c =20 Tue Nov 18 14:34:14 2008 +0800 +++ b/tools/libxc/xc_domain_restore.c Fri Nov 21 =20 17:34:15 2008 +0800 @@ -328,6 +328,16 @@ =20 /* For info only */ nr_pfns =3D 0; + //jsong@novell.com, james song + memset(&domctl, 0, sizeof(domctl)); + domctl.domain =3D dom; + domctl.cmd =3D =20 XEN_DOMCTL_restoredomain; + frc =3D do_domctl(xc_handle, &domctl)= ; + if ( frc !=3D 0 ) + { + ERROR("Unable to set flag of restore."); + goto out; + } =20 if ( read_exact(io_fd, &p2m_size, =20 sizeof(unsigned long)) ) { @@ -1120,6 +1130,8 @@ =20 /* restore saved vcpu_info and arch specific info=20 */ MEMCPY_FIELD(new_shared_info, old_shared_info, vcpu_info); + MEMCPY_FIELD(new_shared_info, =20 old_shared_info, wc_nsec); + MEMCPY_FIELD(new_shared_info, =20 old_shared_info, wc_sec); MEMCPY_FIELD(new_shared_info, old_shared_info, =20 arch); =20 /* clear any pending events and the selector =20 */ diff -r a5ed0dbc829f xen/arch/x86/time.c --- a/xen/arch/x86/time.c Tue Nov 18=20 14:34:14 2008 +0800 +++ b/xen/arch/x86/time.c Fri Nov 21 17:34:15 2008 +0800 @@ -689,7 +689,6 @@ wmb(); (*version)++; } - void update_vcpu_system_time(struct vcpu =20 *v) { struct cpu_time *t; @@ -703,7 +702,6 @@ =20 if ( u->tsc_timestamp =3D=3D t->local_tsc_stamp = =20 ) return; - version_update_begin(&u->version); =20 u->tsc_timestamp =3D t->local_tsc_stamp; @@ -713,14 +711,19 @@ =20 version_update_end(&u->version); } - void update_domain_wallclock_time(struct domain =20 *d) { spin_lock(&wc_lock); + if(d->after_restore ) + { + d->after_restore =3D 0; + goto out; //jsong@novell.com + } version_update_begin(&shared_info(d, =20 wc_version)); shared_info(d, wc_sec) =3D wc_sec + = =20 d->time_offset_seconds; shared_info(d, wc_nsec) =3D wc_nsec= ; version_update_end(&shared_info(d, wc_version)); +out: spin_unlock(&wc_lock); } =20 @@ -751,7 +754,6 @@ u64 x; u32 y, _wc_sec, _wc_nsec; struct domain *d; - x =3D (secs * 1000000000ULL) + (u64)nsecs - = =20 system_time_base; y =3D do_div(x, 1000000000); =20 @@ -1050,7 +1052,6 @@ struct tm wallclock_time(void) { uint64_t seconds; - if ( !wc_sec ) return (struct tm) { 0 }; =20 diff -r a5ed0dbc829f xen/common/domctl.c --- a/xen/common/domctl.c Tue Nov 18 14:34:14 2008 +0800 +++ b/xen/common/domctl.c Fri Nov 21=20 17:34:15 2008 +0800 @@ -24,7 +24,6 @@ #include #include #include - extern long arch_do_domctl( struct xen_domctl *op,=20 XEN_GUEST_HANDLE(xen_domctl_t) u_domctl); =20 @@ -315,6 +314,16 @@ ret =3D 0; } break; + case XEN_DOMCTL_restoredomain: + { + struct domain *d; + if ( (d =3D =20 rcu_lock_domain_by_id(op->domain)) =3D=3D NULL ) + break; + =20 + d->after_restore =3D 1; + rcu_unlock_domain(d); + break; + } =20 case XEN_DOMCTL_createdomain: { diff -r a5ed0dbc829f =20 xen/include/public/domctl.h --- a/xen/include/public/domctl.h Tue Nov 18 14:34:14 2008 +0800 +++ b/xen/include/public/domctl.h Fri Nov 21=20 17:34:15 2008 +0800 @@ -61,6 +61,7 @@ #define XEN_DOMCTL_destroydomain 2 #define XEN_DOMCTL_pausedomain =20 3 #define XEN_DOMCTL_unpausedomain 4 +#define XEN_DOMCTL_restoredomain =20 51 #define XEN_DOMCTL_resumedomain =20 27 =20 #define XEN_DOMCTL_getdomaininfo 5 diff -r a5ed0dbc829f xen/include/xen/sched.h --- a/xen/include/xen/sched.h Tue Nov 18 14:34:14 2008 +0800 +++ b/xen/include/xen/sched.h Fri Nov 21 =20 17:34:15 2008 +0800 @@ -231,6 +231,7 @@ * cause a deadlock. Acquirers don't spin waiting; they preempt. */ spinlock_t hypercall_deadlock_mutex; + int after_restore; =20 //jsong@novell.com }; =20 struct domain_setup_info -------------------------------------------------------------------------= -------------------- Thanks --Song wei --=__Part9AB2F0BE.2__= Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable F.Y.I

>>> "Tian, Kevin" 08.11.27.  11:50 >>>
Sorry for a typo. I did mean = domU instead of dom0. :-) The=20 point here is that time_resume will sync to new system time and wall clock = at=20 restore, and thus pv guest should be able to continue... Xen system time = is not=20 wallclock time which just counts up from power up. As Keir points = out, only=20 its progress is used to drive internal jiffies.
= --- Actually, save/restore or migrate will not call time_resume, this = function mybe only be called in power saving.
Then what do you mean for = "system time stop" here? TOD=20 at user level, or within kernel you observe xen system time never=20 changing?
--- If you run command = "date" in user mode, you will find the date of output never change until a = time interval equal to the value of time delay. And also, you can run some = applicatin without many relation with time. such as vi,cd...etc, but if = you run ping x.x.x.x you will find only one line's respose and never go = on.

 Thanks
 --James

From: James Song [mailto:jsong@no= vell.com]=20
Sent: Thursday, November 27, 2008 11:20 AM
To:=20 keir.fraser@eu.citrix.com; Tian, Kevin;=20 xen-devel@lists.xensource.com
Subject: =B4=F0=B8=B4=A3=BA Re: = [Xen-devel] when=20 timer go back in dom0 save and restore ormigrate, PV domain=20 hung

Hi,
    yes, there is a patch before to = fix=20 problem wc_sec/wc_nsec in xc_domain_restore.c, but it still missed=20 something.
If constucting dom0 or restoring of a PV dom. Guest os = will read=20 the local wc_sec from xen as it base time.wc_sec is initialized with = CMOS=20 data. There were some case which wc_sec will be changed. One is that go = back=20 dom0's system-time will change dom0's time and wc_sec smaller which is = both=20 Guest os and Xen. Actually, we can do a simple test, starting a pv = domain,=20 then change dom0's time, and you will find the system time of guest = os=20 stopped. That because you change wc_sec of both xen and guest os.=20
    This patch only consider the case of save/restore.= I=20 still not sure the policy of this case that is when dom0's system-time = go=20 back. what VMs should do?  So, I have add this case to this=20 patch
   By the way, Kevin, Guest OS will hang not dom0 ;-) = and=20 also the time of hang just is equivlant to the time interval you go back = in=20 dom0 or new machine you migrate.
 Thanks
  --=20 James

>>> Keir Fraser 08?11?26= ? ??=20 22:58 >>> So what happens if someone changes wallclock = using=20 'date'? That's basically kind of what will appear to happen when s/r=20 occurs.

 -- Keir

On 26/11/08 14:32, "Tian, Kevin"=20 <kevin.tian@intel.com> wrote:
hrtimer supports two timer bases: CLOCK_MONOTONIC and=20 CLOCK_REALTIME. wall_to_monotonic is only added in former case, and = for=20 latter instead TOD is used directly per my reading. I did a quick = search,=20 and it looks that futex and ntp are using CLOCK_REALTIME. Also there's = one=20 vsyscall gate which can pass CLOCK_REALTIME from caller=20 too.

Thanks,
Kevin
=

 
From: Keir Fraser  [mailto:keir.fraser@eu.citrix.c= om]=20
Sent: Wednesday, November 26,  2008 10:26 PM
To= :=20 Tian, Kevin; 'James Song';=20  xen-devel@lists.xensource.com
Subject: Re: [Xen-devel= ]=20 when timer go  back in dom0 save and restore or migrate, PV = domain=20 hung

 hrtimers add=20 wall_to_monotonic to xtime to get a  timesource that doesn't = (or=20 shouldn't!) warp.

 -- Keir

On  26/11/08 = 14:20,=20 "Tian, Kevin" <kevin.tian@intel.com>=20  wrote:

 
= how about hrtimers? one mode is CLOCK_REALTIME, which = uses=20  getnstimeofday as expiration. Once system time is changed = either=20 in local or  new machine, that expiration can't be adjusted. = but=20 i'm not sure whether it  still makes sense to try hrtimers in = a=20 guest.

Thanks
Ke= vin

 

 
 
From: Keir Fraser  [mailto:keir.fraser@eu.citrix.c= om]=20  
Sent: Wednesday, November 26,  2008 = 10:11=20 PM
To:  Tian, Kevin; 'James Song';=20   xen-devel@lists.xensource.com
Subject: = Re:=20 [Xen-devel]  when timer go  back in dom0 save and = restore or=20 migrate, PV domain  hung

 
The  problem=20 hasn't been fully explained, but I can say  that PV = guests=20  expect system time to jump across s/r and deal with that. = For=20   example, Linux doesn't use Xen system time internally= , but=20 uses its  progress  to periodically update jiffies, = which=20 does not warp across  s/r.

We have  had = problems=20 corrupting wc_sec/wc_nsec in  xc_domain_restore.c, but that = was=20  fixed some time  ago.

 -- Keir

On= =20 26/11/08 14:00, "Tian,  Kevin"  <kevin.tian@intel.co= m>=20 wrote:

 
 
This is not a s/r or lm specific issue. For = example,=20 system  time  can be changed even when pv guest = is=20 running. Your patch only  hacks restore  point once, = and=20 wc_sec can still be changed later  when system time is=20  changed on-the-fly  again.

IIRC, pv guest can catch up wall=20 clock change in timer  interrupt,  and time_resume = will=20 sync internal processed system  time with new system =  time=20 after restored. But I'm not sure whether  it's enough. = Actually=20 the more  interesting is the uptime  difference. = For=20 example, timer with expiration  calculated on  previo= us=20 system time may wait nearly infinite if uptime among =  two=20  boxes vary a lot. But I think such issue should have = been=20 considered   already, e.g. some user tool assistance.= I=20 think Keir can comment  better=20  here.

BTW, do you = happen to know what=20 exactly dom0 hangs on? In  some  busy loop to catch = up=20 time, or long delay to some critical  timer=20  expiration?

T= hanks,
Kevin

 
 

 
 
 
From:=20   xen-devel-bounces@lists.xensource.com  [mailto:xen-devel-b= ounces@lists.xensource.com]=20   On Behalf Of James  Song
Sent:<= /b>=20 Tuesday,  November 25,  2008 4:02 PM
To:= =20    xen-devel@lists.xensource.com
Subject= :=20  [Xen-devel] when  timer go  back in dom0 = save and=20 restore or  migrate, PV domain  hung

 
Hi,
   = ;I=20   find PV domin hung, When we take those steps=20    
      &nb= sp;  1,=20  save PV  domain=20   
       &nb= sp; 2,=20   change system time of  PV domain back=20   
       &nb= sp; 3,=20  restore   a PV domain=20  
        or= =20    
      &nb= sp;  1,=20  migrate  a PV domain  from Machine A to = Machine=20   B
       &n= bsp; 2,=20  the system   time of Machine B is slower = than=20 Machine  A.
   the  problem = is=20  wc_sec will be  change when system-time chanaged = in=20 dom0  or restore in a   slower-system-time = machine,=20 but when restoring, xen  don't  restore the = wc_sec=20  of share_info from xenstore and use native   = one.=20 So guest os will hang.  
this patch will work for=20  this  issue.

 Thanks
 -- = Song=20   Wei

diff -r  a5ed0dbc829f=20  tools/libxc/xc_domain_restore.c
---=20    a/tools/libxc/xc_domain_restore.c=20    Tue  Nov 18  14:34:14 2008=20  +0800
+++  b/tools/libxc/xc_domain_restore.c=20=     Fri Nov 21   17:34:15 = 2008=20 +0800
@@ -328,6  +328,16=20   @@
 
     /* = For=20 info   only=20  */
     nr_pfns =3D = 0;
+=20       //jsong@novell.com, = james=20 song
+      memset(&domctl, = 0,=20   sizeof(domctl));
+=20     domctl.domain =3D   dom;+=20     domctl.cmd    =3D=20    XEN_DOMCTL_restoredomain;
+=20    frc =3D   do_domctl(xc_handle,=20=  &domctl);
+     if ( frc =  !=3D=20 0 )
+      {
+=20           &= nbsp;   ERROR("Unable=20   to set flag of  restore.");
+=20           &= nbsp;   goto=20   out;
+=20      }
 
  &nbs= p;  if=20  (   read_exact(io_fd, &p2m_size,=20 sizeof(unsigned long))=20    )
     {
@@= =20 -1120,6 +1130,8=20    @@
 
    &nb= sp;/*=20 restore  saved  vcpu_info and arch  specific = info=20   */
     MEMCPY_FIELD(= new_shared_info,=20    old_shared_info, vcpu_info);
+=20       MEMCPY_FIELD(new_shared_i= nfo,=20  old_shared_info,   wc_nsec);
+=20     MEMCPY_FIELD(new_shared_info,=20    old_shared_info,=20   wc_sec);
      M= EMCPY_FIELD(new_shared_info,=20   old_shared_info,=20    arch);
 
    = ; /*=20 clear  any  pending events and  the = selector=20 */
diff -r  a5ed0dbc829f  xen/arch/x86/time.c---=20   a/xen/arch/x86/time.c     Tue= Nov=20 18  14:34:14 2008 +0800
+++=20   b/xen/arch/x86/time.c     Fri= Nov=20 21 17:34:15 2008  +0800
@@   -689,7 = +689,6=20   @@
      wmb();<= br>     (*version)++;
 }
-
 voi= d=20    update_vcpu_system_time(struct vcpu=20   *v)
 {
     &= nbsp;struct=20  cpu_time        *t;<= br>@@=20 -703,7  +702,6=20   @@
 
     if = (=20   u->tsc_timestamp =3D=3D  t->local_tsc_= stamp=20   )
       &n= bsp;  return;
-
      version= _update_begin(&u->version);
 
    &nb= sp; u->tsc_timestamp=20       =3D t->local_tsc_stamp= ;
@@=20   -713,14  +711,19=20   @@
 
     &nb= sp;version_update_end(&u->version);
 }
-
 void=20=    update_domain_wallclock_time(struct = domain=20    *d)
 {
    &= nbsp; spin_lock(&wc_lock);
+=20      if(d->after_restore =  )
+=20      {
+=20           d= ->after_restore=20  =3D  0;
+=20        goto   ou= t;=20  //jsong@novell.com
+=20      }
    &n= bsp; version_update_begin(&shared_info(d,=20    wc_version));
    &n= bsp;shared_info(d,=20   wc_sec)  =3D  wc_sec +=20   d->time_offset_seconds;
   &= nbsp; shared_info(d,=20    wc_nsec) =3D=20   wc_nsec;
      v= ersion_update_end(&shared_info(d,=20    wc_version));
+out:
   = ;   spin_unlock(&wc_lock);
 }
 
@@=20=   -751,7 +754,6=20  @@
     u64=20   x;
     u32 y,=20  _wc_sec,=20   _wc_nsec;
     struct= =20 domain=20    *d;
-
     x= =3D=20 (secs *  1000000000ULL)  + (u64)nsecs -=20   system_time_base;
    &nbs= p;y=20  =3D  do_div(x,  1000000000);
 
@@ = -1050,7=20 +1052,6   @@
 struct tm=20    wallclock_time(void)
 {
 &n= bsp;   uint64_t=20    seconds;
-
    &n= bsp;if=20 (  !wc_sec=20    )
      &n= bsp;  return=20   (struct tm) { 0  };
 
diff -r=20 a5ed0dbc829f   xen/common/domctl.c
---=20  a/xen/common/domctl.c      Tue= Nov=20 18 14:34:14 2008 +0800
+++=20    b/xen/common/domctl.c    Fri= Nov=20 21  17:34:15 2008  +0800
@@  -24,7 = +24,6=20 @@
 #include=20   <asm/current.h>
 #include=20    <public/domctl.h>
 #include= =20    <xsm/xsm.h>
-
 extern = long=20    arch_do_domctl(
    =  struct=20  xen_domctl  *op,  XEN_GUEST_HANDLE(xen_domctl= _t)=20  u_domctl);
 
@@  -315,6 +314,16=20    @@
      &= nbsp;  ret=20  =3D=20    0;
     }
&n= bsp;     break;
+=20     case XEN_DOMCTL_restoredomain:
+= =20     {
+=20          struct= =20 domain   *d;
+=20         if ( (d =  =3D=20   rcu_lock_domain_by_id(op->domain)) =3D=3D = NULL=20   )
+=20           &= nbsp;   break;
+=20           <= br>+=20          d->a= fter_restore=20 =3D    1;
+=20           r= cu_unlock_domain(d);
+=20           b= reak;
+=20     }
 
   &nbs= p; case=20    XEN_DOMCTL_createdomain:
  &nb= sp;  {
diff=20   -r a5ed0dbc829f=20  xen/include/public/domctl.h
---=20    a/xen/include/public/domctl.h=20    Tue Nov 18  14:34:14  2008=20  +0800
+++ b/xen/include/public/domctl.h=20      Fri Nov 21  17:34:15 = 2008=20 +0800
@@  -61,6 +61,7  @@
 #define=20  XEN_DOMCTL_destroydomain=20        2
 #define= =20    XEN_DOMCTL_pausedomain=20           3=
 #define=20   XEN_DOMCTL_unpausedomain=20        4
+#define=20   XEN_DOMCTL_restoredomain=20         51
 #= define=20   XEN_DOMCTL_resumedomain=20         27
 <= br> #define=20    XEN_DOMCTL_getdomaininfo=20       5
diff -r=20   a5ed0dbc829f  xen/include/xen/sched.h
---= =20   a/xen/include/xen/sched.h     = ;Tue=20 Nov 18 14:34:14 2008   +0800
+++=20  b/xen/include/xen/sched.h    Fri Nov = 21=20  17:34:15   2008 +0800
@@ -231,6 +231,7=20   @@
      * = cause a=20   deadlock.  Acquirers don't spin waiting; = they=20    preempt.
     &= nbsp;*/
      spinlock_t=20   hypercall_deadlock_mutex;
+    = int=20  after_restore;=20    //jsong@novell.com
 };
  struct=20    domain_setup_info
----------------------= -----------------------------------------------------------------------
=  Thanks
--Song=20    wei







--=__Part9AB2F0BE.2__=-- --===============1335942090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1335942090==--