WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH][RESEND] xm reboot for vmx domain

To: "Yu, Ke" <ke.yu@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][RESEND] xm reboot for vmx domain
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Thu, 10 Nov 2005 11:17:58 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 10 Nov 2005 11:18:12 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8126E4F969BA254AB43EA03C59F44E8403D53986@pdsmsx404>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <8126E4F969BA254AB43EA03C59F44E8403D53986@pdsmsx404>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Thu, Nov 10, 2005 at 06:08:52PM +0800, Yu, Ke wrote:

> This patch fixes the bug that "xm reboot <domid>" can not reboot vmx
> domain.
> 
> In xm reboot process, control panel will wait until DomU notified it.
> Unlike DomU, vmx domain can not passively do that, since it runs
> unmodified OS. This patch adds the missing logic in control panel.
> Any comment? 
> 
> Signed-off-by: Xu Dan <dan.d.xu@xxxxxxxxx >
>              Yu Ke <ke.yu@xxxxxxxxx>

Content-Description: reboot1.patch
> [-- mutt.octet.filter file type: "'diff' output text" --]
> 
> [-- Statistics (lines words chars):  29 118 1176 /tmp/reboot1.patch --]
> 
> diff -r 0240a69e1f97 tools/python/xen/xend/XendDomainInfo.py
> --- a/tools/python/xen/xend/XendDomainInfo.py Wed Oct 26 13:59:29 2005
> +++ b/tools/python/xen/xend/XendDomainInfo.py Thu Oct 27 17:03:08 2005
> @@ -680,6 +680,14 @@
>          """Get this domain's target memory size, in KiB."""
>          return self.info['memory_KiB']
>  
> +    def vmx_get_xeninfo(self, xeninfo):
> +        """Get vmx xeninfo"""
> +        shutdown_reason = self.readDom('control/shutdown')
> +        if shutdown_reason:
> +            xeninfo['shutdown'] = 1
> +            for x in shutdown_reasons.keys():
> +                if shutdown_reasons[x] == shutdown_reason:
> +                    xeninfo['shutdown_reason'] = x
>  
>      def refreshShutdown(self, xeninfo = None):
>          # If set at the end of this method, a restart is required, with the
> @@ -701,6 +709,10 @@
>                      # machine.
>                      self.cleanupDomain()
>                      return
> +
> +            if self.image:
> +                if self.image.ostype == "vmx":
> +                    self.vmx_get_xeninfo(xeninfo)
>  
>              if xeninfo['dying']:
>                  # Dying means that a domain has been destroyed, but has not

Thanks for your resend, and sorry for not replying sooner.

The reason I did not apply this immediately is that I am concerned by the
arrangement here.  Up until now, all VMX-related code has been isolated in
image.py, but your patch brings VMX code directly into XendDomainInfo.py, and
I would like to avoid doing that if possible.

I am also concerned about race conditions.  The control/shutdown node is used
to tell the domain to shut down, but you are using it also as a flag to tell
Xend that the domain has actually shut down.  This means that if
refreshShutdown is called before the VMX guest has had time to see a new
control/shutdown entry, then Xend will think that the domain has shut down
even before it has started to do so.

I think that this patch needs some thought before it goes in.  Perhaps we
could discuss my concerns and move forward from there.

Thanks,

Ewan.

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

<Prev in Thread] Current Thread [Next in Thread>