Xen devel - Aug 2006 - [Patch] Enable "sysrq c" handler for domU coredump

Hi,

In the case of linux, crash_kexec() is occured by "sysrq c".
In the case of DomainU on xen, Help is occured by "sysrq c" now.
So The way of dumping DomainU''s memory manualy is nothing.

I fix this issue by the following way.
1. Panic is occured by "sysrq c" on both Domain0 and DomainU.
2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).
   On Domain0, crash_kexec() is called by panic() if implemented.

I tested the below.
1. vi /etc/xen/xend-config.sxp
   (enabel-dump yes)
2. xm create -c domU
   echo 1 >/proc/sys/kernel/sysrq (on domU)
3. xm sysrq domU c (on dom0)
4. ls -lh /var/xen/dump

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>

Best Regards,

Akio Takebe


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

On Tue, Aug 01, 2006 at 12:11:26PM +0900, Akio Takebe wrote:
Content-Description: Mail message body
> Hi,
> 
> In the case of linux, crash_kexec() is occured by "sysrq c".
> In the case of DomainU on xen, Help is occured by "sysrq c" now.
> So The way of dumping DomainU''s memory manualy is nothing.
> 
> I fix this issue by the following way.
> 1. Panic is occured by "sysrq c" on both Domain0 and DomainU.
> 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).
>    On Domain0, crash_kexec() is called by panic() if implemented.
> 
> I tested the below.
> 1. vi /etc/xen/xend-config.sxp
>    (enabel-dump yes)
> 2. xm create -c domU
>    echo 1 >/proc/sys/kernel/sysrq (on domU)
> 3. xm sysrq domU c (on dom0)
> 4. ls -lh /var/xen/dump
> 
> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
> Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
That seems fine to me. Though there was some resistance to a
patch I sent which adds a panic option to xen-console, which
is the hypervisor equivalent of sysrq.

Also, is this option really Xen specific. It seems it
might be just as useful in regular Linux.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/


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

Hi, Horms
>
>That seems fine to me. Though there was some resistance to a
>patch I sent which adds a panic option to xen-console, which
>is the hypervisor equivalent of sysrq.
>
This patch focus only manually dumping domU''s core.
How can I use the panic option of xen-console?
I thought your patch to panic xen.
Can I dump domU''s core with the option?
>Also, is this option really Xen specific. It seems it
>might be just as useful in regular Linux.
This is a patch to dump domU''s core,
so Linux is not useful becaus Linux can dump by calling crash_kexec().

Best Regards,

Akio Takebe

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

On Tue, Aug 01, 2006 at 01:39:23PM +0900, Akio Takebe
wrote:
> Hi, Horms
> 
> >
> >That seems fine to me. Though there was some resistance to a
> >patch I sent which adds a panic option to xen-console, which
> >is the hypervisor equivalent of sysrq.
> >
> This patch focus only manually dumping domU''s core.
> How can I use the panic option of xen-console?
> I thought your patch to panic xen.
> Can I dump domU''s core with the option?
Sorry, I was not clear.

Yes, my patch is to panic (or more recently cause a crash dump) 
in the hypervisor. It does not give any special behaviour to
the domains.

What I meant was, that the idea of adding a panic to domU''s sysrq
is similar to my idea of adding panic to the xen console. And I was
asked to change this patch to make it trigger a kdump directly,
rather than a panic.

I think that your sysrq patch and my xen-console panic patches
are related, and I wanted to bring that into the discussion.
> >Also, is this option really Xen specific. It seems it
> >might be just as useful in regular Linux.
>
> This is a patch to dump domU''s core,
> so Linux is not useful becaus Linux can dump by calling crash_kexec().
Right, but it does this using panic() which does have some effect
in regular Linux. I am just wondering if your solution answers
a more generic question than how to dump domU.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/


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

On 1 Aug 2006, at 04:11, Akio Takebe wrote:
> In the case of linux, crash_kexec() is occured by "sysrq c".
> In the case of DomainU on xen, Help is occured by "sysrq c" now.
> So The way of dumping DomainU''s memory manualy is nothing.
I don''t think we''re going to modify a previously untouched
Linux file
to add support for this.

  -- Keir


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

On 1 Aug 2006, at 09:15, Muli Ben-Yehuda wrote:
>>> In the case of linux, crash_kexec() is occured by "sysrq
c".
>>> In the case of DomainU on xen, Help is occured by "sysrq
c" now.
>>> So The way of dumping DomainU''s memory manualy is nothing.
>>
>> I don''t think we''re going to modify a previously
untouched Linux file
>> to add support for this.
>
> If we were using a proper Linux kernel tree and not the sparse tree
> this wouldn''t have been a problem...
My problem is not with adding another file to the sparse tree, it''s 
modifying another file that ought to be none of our business for a 
feature of dubious worth (maybe useful for kexec/kdump debugging I 
suppose).

  -- Keir


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

On Tue, Aug 01, 2006 at 09:03:10AM +0100, Keir Fraser
wrote:
> 
> On 1 Aug 2006, at 04:11, Akio Takebe wrote:
> 
> >In the case of linux, crash_kexec() is occured by "sysrq c".
> >In the case of DomainU on xen, Help is occured by "sysrq c"
now.
> >So The way of dumping DomainU''s memory manualy is nothing.
> 
> I don''t think we''re going to modify a previously
untouched Linux file
> to add support for this.
If we were using a proper Linux kernel tree and not the sparse tree
this wouldn''t have been a problem...

(sorry, couldn''t resist)

Cheers,
Muli

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

>On Tue, Aug 01, 2006 at 01:39:23PM +0900, Akio Takebe wrote:
>> Hi, Horms
>> 
>> >
>> >That seems fine to me. Though there was some resistance to a
>> >patch I sent which adds a panic option to xen-console, which
>> >is the hypervisor equivalent of sysrq.
>> >
>> This patch focus only manually dumping domU''s core.
>> How can I use the panic option of xen-console?
>> I thought your patch to panic xen.
>> Can I dump domU''s core with the option?
>
>Sorry, I was not clear.
>
>Yes, my patch is to panic (or more recently cause a crash dump) 
>in the hypervisor. It does not give any special behaviour to
>the domains.
>
>What I meant was, that the idea of adding a panic to domU''s sysrq
>is similar to my idea of adding panic to the xen console. And I was
>asked to change this patch to make it trigger a kdump directly,
>rather than a panic.
>
>I think that your sysrq patch and my xen-console panic patches
>are related, and I wanted to bring that into the discussion.
>
Horms, what you said, that I had better call crash_kexec() 
than panic() on dom0?
If so, I agree for dom0 directly calling crash_kexec().
But because now vmlinux is used as both dom0 and domU,
we cannot use ifdef for separateing dom0 and domU.
So I call panic() on both dom0 and domU.
I also think option like a unknown_nmi_panic is useful 
and necessary for dump and debug.

Everyone, how about the below?
1. If crash_kexec() is called on dom0, dom0 do hypercall
   then xen do kexec/kdump
2. If crash_kexec() is called on domU, domU do hypercall
   then xen do panic_domain(), and domU''s core is dumped.

So I don''t need to modify linux code. :-)

Or How about "xm dump"?
(Probably I use panic_domain() by hypercall.
This way can probably dump HVM domain.)

I think we need to have the way manually to dump domU, or Xen.
(Because for the time when domU or Xen don''t panic 
and spinloop and so on) 

Best Regards,

Akio Takebe

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

On Tue, Aug 01, 2006 at 06:06:35PM +0900, Akio Takebe
wrote:
> >On Tue, Aug 01, 2006 at 01:39:23PM +0900, Akio Takebe wrote:
> >> Hi, Horms
> >> 
> >> >
> >> >That seems fine to me. Though there was some resistance to a
> >> >patch I sent which adds a panic option to xen-console, which
> >> >is the hypervisor equivalent of sysrq.
> >> >
> >> This patch focus only manually dumping domU''s core.
> >> How can I use the panic option of xen-console?
> >> I thought your patch to panic xen.
> >> Can I dump domU''s core with the option?
> >
> >Sorry, I was not clear.
> >
> >Yes, my patch is to panic (or more recently cause a crash dump) 
> >in the hypervisor. It does not give any special behaviour to
> >the domains.
> >
> >What I meant was, that the idea of adding a panic to domU''s
sysrq
> >is similar to my idea of adding panic to the xen console. And I was
> >asked to change this patch to make it trigger a kdump directly,
> >rather than a panic.
> >
> >I think that your sysrq patch and my xen-console panic patches
> >are related, and I wanted to bring that into the discussion.
> >
> Horms, what you said, that I had better call crash_kexec() 
> than panic() on dom0?
Thats not what I was thinking, but now you mention it...
> If so, I agree for dom0 directly calling crash_kexec().
> But because now vmlinux is used as both dom0 and domU,
> we cannot use ifdef for separateing dom0 and domU.
> So I call panic() on both dom0 and domU.
> I also think option like a unknown_nmi_panic is useful 
> and necessary for dump and debug.
> 
> Everyone, how about the below?
> 1. If crash_kexec() is called on dom0, dom0 do hypercall
>    then xen do kexec/kdump
> 2. If crash_kexec() is called on domU, domU do hypercall
>    then xen do panic_domain(), and domU''s core is dumped.
I think that is a good idea, because it gives consistent behaviour
for dom0 and domU, even though the mechanics differ. Though if
kexec for domU is merged, things may change at that time.
> So I don''t need to modify linux code. :-)
:-)
> Or How about "xm dump"?
> (Probably I use panic_domain() by hypercall.
> This way can probably dump HVM domain.)
That is also a good idea, though it could be done as well,
rather than instead of your crash_kexec() -> hypercall idea.
> I think we need to have the way manually to dump domU, or Xen.
> (Because for the time when domU or Xen don''t panic 
> and spinloop and so on) 
That is a good point, which makes your xm dump idea somewhat
more attactive than the crash_kexec() -> hypercall idea.
But I still think they both make sense.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/


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

Hi, Horms
> Everyone, how about the below?
>> 1. If crash_kexec() is called on dom0, dom0 do hypercall
>>    then xen do kexec/kdump
>> 2. If crash_kexec() is called on domU, domU do hypercall
>>    then xen do panic_domain(), and domU''s core is dumped.
>
>I think that is a good idea, because it gives consistent behaviour
>for dom0 and domU, even though the mechanics differ. Though if
>kexec for domU is merged, things may change at that time.
>
>> So I don''t need to modify linux code. :-)
>
>:-)
>
>> Or How about "xm dump"?
>> (Probably I use panic_domain() by hypercall.
>> This way can probably dump HVM domain.)
>
>That is also a good idea, though it could be done as well,
>rather than instead of your crash_kexec() -> hypercall idea.
>
>> I think we need to have the way manually to dump domU, or Xen.
>> (Because for the time when domU or Xen don''t panic 
>> and spinloop and so on) 
>
>That is a good point, which makes your xm dump idea somewhat
>more attactive than the crash_kexec() -> hypercall idea.
>But I still think they both make sense.
OK, I''ll make "xm dump" soon.
Please wait.

Best Regards,

Akio Takebe

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

Hi, Keir and Horms

This patch is sample patch.
I make "xm dump" command with dom0_ops.
xc_domain_dump() only call __domain_crash().
After __domain_crash(), xend start dumpcore 
because shutdown status is crash.
(When enabel-dump in xend-cofig.sxp is yes)

The xm dump usage is below.
1. vi /etc/xen/xend-config.sxp
   (enable-dump yes)
2. xend start
3. xm create domU
4. xm dump domU
5. coredump is created in /var/xen/dump/

I think this way can probably dump both nonHVM and HVM domain''s core.
But I tested only nonHVM domain (because I don''t have HVM machine).

How about this implementation?

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>

Best Regards,

Akio Takebe

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

On Thu, Aug 03, 2006 at 09:18:23AM +0900, Akio Takebe wrote:
> This patch is sample patch.
> I make "xm dump" command with dom0_ops.
> xc_domain_dump() only call __domain_crash().
It would be /much/ more useful to be able to make it dump without taking
down the domain (just pause it, take the crash dump, then let it
continue).

I''ve been meaning to look at this (in my head it was ''xm
gcore'') for a
long time but haven''t found the time.

regards
john

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

On Thu, Aug 03, 2006 at 09:18:23AM +0900, Akio Takebe wrote:
Content-Description: Mail message body
> Hi, Keir and Horms
> 
> This patch is sample patch.
> I make "xm dump" command with dom0_ops.
> xc_domain_dump() only call __domain_crash().
> After __domain_crash(), xend start dumpcore 
> because shutdown status is crash.
> (When enabel-dump in xend-cofig.sxp is yes)
> 
> The xm dump usage is below.
> 1. vi /etc/xen/xend-config.sxp
>    (enable-dump yes)
> 2. xend start
> 3. xm create domU
> 4. xm dump domU
> 5. coredump is created in /var/xen/dump/
> 
> I think this way can probably dump both nonHVM and HVM domain''s
core.
> But I tested only nonHVM domain (because I don''t have HVM
machine).
> 
> How about this implementation?
That seems fine to me, though I am no expert on xend.
Some minor comments are inline.
> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
> 
> Best Regards,
> 
> Akio Takebe
> # HG changeset patch
> # User root@procyon
> # Node ID a16cc49dbd01e9c3f78fb5041d782025c2bda2fa
> # Parent  10b05c2e79475f90330fa061b46d6df7e71a41c5
> Support "xm dump" command.
> xc_domain_dump() only call __domain_crash().
> After __domain_crash(), xend start dumpcore 
> because shutdown status is crash.
> (When enabel-dump in xend-cofig.sxp is yes)
> 
> The xm dump usage is below.
> 1. vi /etc/xen/xend-config.sxp
>    (enable-dump yes)
> 2. xend start
> 3. xm create domU
> 4. xm dump domU
> 5. coredump is created in /var/xen/dump/
> 
> Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
> 
> diff -r 10b05c2e7947 -r a16cc49dbd01 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Tue Aug 01 18:08:01 2006 +0100
> +++ b/tools/libxc/xc_domain.c	Thu Aug 03 09:20:16 2006 +0900
> @@ -28,6 +28,14 @@ int xc_domain_create(int xc_handle,
>      return 0;
>  }
>  
> +int xc_domain_dump(int xc_handle,
> +                    uint32_t domid)
> +{
> +    DECLARE_DOM0_OP;
> +    op.cmd = DOM0_DUMPDOMAIN;
> +    op.u.dumpdomain.domain = (domid_t)domid;
> +    return do_dom0_op(xc_handle, &op);
> +}
>  
>  int xc_domain_pause(int xc_handle,
>                      uint32_t domid)
> diff -r 10b05c2e7947 -r a16cc49dbd01 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Tue Aug 01 18:08:01 2006 +0100
> +++ b/tools/libxc/xenctrl.h	Thu Aug 03 09:20:16 2006 +0900
> @@ -202,6 +202,17 @@ int xc_domain_unpause(int xc_handle,
>                        uint32_t domid);
>  
>  /**
> + * This function dump a domain. A domain_dump only crash domain.
> + * after crash domain, xc_domain_dumpcore dump domain memory.
Perhaps:

  /**
   * This function dumps a domain to a core file. It does this by
   * crashing the domain, after which xc_domain_dumpcore() will dump the
   * domain''s memory.
> + *
> + * @parm xc_handle a handle to an open hypervisor interface
> + * @parm domid the domain id to pause
> + * @return 0 on success, -1 on failure.
> + */
> +int xc_domain_dump(int xc_handle,
> +                    uint32_t domid);
> +
> +/**
>   * This function will destroy a domain.  Destroying a domain removes the
domain
>   * completely from memory.  This function should be called after sending
the
>   * domain a SHUTDOWN control message to free up the domain resources.
> diff -r 10b05c2e7947 -r a16cc49dbd01 tools/python/xen/lowlevel/xc/xc.c
> --- a/tools/python/xen/lowlevel/xc/xc.c	Tue Aug 01 18:08:01 2006 +0100
> +++ b/tools/python/xen/lowlevel/xc/xc.c	Thu Aug 03 09:20:16 2006 +0900
> @@ -117,6 +117,11 @@ static PyObject *pyxc_domain_max_vcpus(X
>      
>      Py_INCREF(zero);
>      return zero;
> +}
> +
> +static PyObject *pyxc_domain_dump(XcObject *self, PyObject *args)
> +{
> +    return dom_op(self, args, xc_domain_dump);
>  }
>  
>  static PyObject *pyxc_domain_pause(XcObject *self, PyObject *args)
> @@ -945,6 +950,13 @@ static PyMethodDef pyxc_methods[] = {
>        "Dump core of a domain.\n"
>        " dom [int]: Identifier of domain to dump core of.\n"
>        " corefile [string]: Name of corefile to be created.\n\n"
> +      "Returns: [int] 0 on success; -1 on error.\n" },
> +
> +    { "domain_dump", 
> +      (PyCFunction)pyxc_domain_dump, 
> +      METH_VARARGS, "\n"
> +      "Dump of a domain.\n"
The description sof domain_dumpcore vs domain_dump above
are somewhat ambigious. Could you make it clearer what
the difference between the two is?

Perhaps:
         "Crash a domain so that it will dump core\n"
> +      " dom [int]: Identifier of domain to dump core of.\n"
>        "Returns: [int] 0 on success; -1 on error.\n" },
>  
>      { "domain_pause", 
> diff -r 10b05c2e7947 -r a16cc49dbd01 tools/python/xen/xend/XendDomain.py
> --- a/tools/python/xen/xend/XendDomain.py	Tue Aug 01 18:08:01 2006 +0100
> +++ b/tools/python/xen/xend/XendDomain.py	Thu Aug 03 09:20:16 2006 +0900
> @@ -355,6 +355,23 @@ class XendDomain:
>              self.domains_lock.release()
>  
>   
> +    def domain_dump(self, domid):
> +        """dump domain''s core."""
> +
> +        dominfo = self.domain_lookup_by_name_or_id_nr(domid)
> +        if not dominfo:
> +            raise XendInvalidDomain(str(domid))
> +
> +        if dominfo.getDomid() == PRIV_DOMAIN:
> +            raise XendError("Cannot dump privileged domain %s" %
domid)
> +
> +        try:
> +            log.info("Domain %s (%d) coredump.",
dominfo.getName(),
> +                     dominfo.getDomid())
> +            return dominfo.dump()
> +        except Exception, ex:
> +            raise XendError(str(ex))
> +
>      def domain_unpause(self, domid):
>          """Unpause domain execution."""
>  
> diff -r 10b05c2e7947 -r a16cc49dbd01
tools/python/xen/xend/XendDomainInfo.py
> --- a/tools/python/xen/xend/XendDomainInfo.py	Tue Aug 01 18:08:01 2006
+0100
> +++ b/tools/python/xen/xend/XendDomainInfo.py	Thu Aug 03 09:20:16 2006
+0900
> @@ -1546,6 +1546,8 @@ class XendDomainInfo:
>      def unpause(self):
>          xc.domain_unpause(self.domid)
>  
> +    def dump(self):
> +        xc.domain_dump(self.domid)
>  
>      ## private:
>  
> diff -r 10b05c2e7947 -r a16cc49dbd01
tools/python/xen/xend/server/SrvDomain.py
> --- a/tools/python/xen/xend/server/SrvDomain.py	Tue Aug 01 18:08:01 2006
+0100
> +++ b/tools/python/xen/xend/server/SrvDomain.py	Thu Aug 03 09:20:16 2006
+0900
> @@ -43,6 +43,10 @@ class SrvDomain(SrvDir):
>                       [''config'',
''sxpr'']])
>          return fn(req.args, {''dom'': self.dom.domid})
>  
> +    def op_dump(self, _1, _2):
> +        val = self.xd.domain_dump(self.dom.domid)
> +        return val
> +        
>      def op_unpause(self, _1, _2):
>          val = self.xd.domain_unpause(self.dom.domid)
>          return val
> diff -r 10b05c2e7947 -r a16cc49dbd01 tools/python/xen/xm/main.py
> --- a/tools/python/xen/xm/main.py	Tue Aug 01 18:08:01 2006 +0100
> +++ b/tools/python/xen/xm/main.py	Thu Aug 03 09:20:16 2006 +0900
> @@ -70,6 +70,7 @@ shutdown_help ="shutdown <DomId> [-w][-a
>  shutdown_help ="shutdown <DomId> [-w][-a][-R|-H] Shutdown a
domain"
>  top_help =     "top                              Monitor system and
domains in real-time"
>  unpause_help = "unpause <DomId>                  Unpause a
paused domain"
> +dump_help =    "dump <DomId>                     dump
domain''s core"
>  
>  help_spacer = """
>     """
> @@ -148,6 +149,7 @@ short_command_list = [
>      "top",
>      "unpause",
>      "vcpu-set",
> +    "dump",
>      ]
>  
>  domain_commands = [
> @@ -173,6 +175,7 @@ domain_commands = [
>      "vcpu-list",
>      "vcpu-pin",
>      "vcpu-set",
> +    "dump",
>      ]
>  
>  host_commands = [
> @@ -585,6 +588,12 @@ def xm_unpause(args):
>      dom = args[0]
>  
>      server.xend.domain.unpause(dom)
> +
> +def xm_dump(args):
> +    arg_check(args, "dump", 1)
> +    dom = args[0]
> +
> +    server.xend.domain.dump(dom)
>  
>  def xm_rename(args):
>      arg_check(args, "rename", 2)
> @@ -1126,6 +1135,7 @@ commands = {
>      # special
>      "pause": xm_pause,
>      "unpause": xm_unpause,
> +    "dump": xm_dump,
>      # host commands
>      "dmesg": xm_dmesg,
>      "info": xm_info,
> diff -r 10b05c2e7947 -r a16cc49dbd01 xen/common/dom0_ops.c
> --- a/xen/common/dom0_ops.c	Tue Aug 01 18:08:01 2006 +0100
> +++ b/xen/common/dom0_ops.c	Thu Aug 03 09:20:16 2006 +0900
> @@ -164,6 +164,23 @@ long do_dom0_op(XEN_GUEST_HANDLE(dom0_op
>      }
>      break;
>  
> +    case DOM0_DUMPDOMAIN:
> +    {
> +        struct domain *d = find_domain_by_id(op->u.dumpdomain.domain);
> +        ret = -ESRCH;
> +        if ( d != NULL )
> +        {
> +            ret = -EINVAL;
> +            if ( d != current->domain )
> +            {
> +                __domain_crash(d);
> +                ret = 0;
> +            }
> +            put_domain(d);
> +        }
> +    }
> +    break;
> +
>      case DOM0_PAUSEDOMAIN:
>      {
>          struct domain *d = find_domain_by_id(op->u.pausedomain.domain);
> diff -r 10b05c2e7947 -r a16cc49dbd01 xen/include/public/dom0_ops.h
> --- a/xen/include/public/dom0_ops.h	Tue Aug 01 18:08:01 2006 +0100
> +++ b/xen/include/public/dom0_ops.h	Thu Aug 03 09:20:16 2006 +0900
> @@ -539,6 +539,14 @@ struct dom0_settimeoffset {
>  };
>  typedef struct dom0_settimeoffset dom0_settimeoffset_t;
>  DEFINE_XEN_GUEST_HANDLE(dom0_settimeoffset_t);
> +
> +#define DOM0_DUMPDOMAIN    51
> +struct dom0_dumpdomain {
> +    /* IN parameters. */
> +    domid_t domain;
> +};
> +typedef struct dom0_dumpdomain dom0_dumpdomain_t;
> +DEFINE_XEN_GUEST_HANDLE(dom0_dumpdomain_t);
>  
>  struct dom0_op {
>      uint32_t cmd;
> @@ -583,6 +591,7 @@ struct dom0_op {
>          struct dom0_hypercall_init    hypercall_init;
>          struct dom0_domain_setup      domain_setup;
>          struct dom0_settimeoffset     settimeoffset;
> +        struct dom0_dumpdomain        dumpdomain;
>          uint8_t                       pad[128];
>      } u;
>  };

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/


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

Le Jeudi 03 Août 2006 02:26, John Levon a écrit :
> On Thu, Aug 03, 2006 at 09:18:23AM +0900, Akio Takebe wrote:
> > This patch is sample patch.
> > I make "xm dump" command with dom0_ops.
> > xc_domain_dump() only call __domain_crash().
>
> It would be /much/ more useful to be able to make it dump without taking
> down the domain (just pause it, take the crash dump, then let it
> continue).
Yes, I think so too.
Akio you have implemented ''xm crash''!  But the feature is
useful too.

Tristan.

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

Hi, Horms

Thank you for your comments.
This is very helpful.
>> diff -r 10b05c2e7947 -r a16cc49dbd01 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Tue Aug 01 18:08:01 2006 +0100
>> +++ b/tools/libxc/xenctrl.h	Thu Aug 03 09:20:16 2006 +0900
>> @@ -202,6 +202,17 @@ int xc_domain_unpause(int xc_handle,
>>                        uint32_t domid);
>>  
>>  /**
>> + * This function dump a domain. A domain_dump only crash domain.
>> + * after crash domain, xc_domain_dumpcore dump domain memory.
>
>Perhaps:
>
>  /**
>   * This function dumps a domain to a core file. It does this by
>   * crashing the domain, after which xc_domain_dumpcore() will dump the
>   * domain''s memory.
>
Yes, you are right.
Your comments is very clear.
I use your comments. :)
>> @@ -945,6 +950,13 @@ static PyMethodDef pyxc_methods[] = {
>>        "Dump core of a domain.\n"
>>        " dom [int]: Identifier of domain to dump core of.\n"
>>        " corefile [string]: Name of corefile to be
created.\n\n"
>> +      "Returns: [int] 0 on success; -1 on error.\n" },
>> +
>> +    { "domain_dump", 
>> +      (PyCFunction)pyxc_domain_dump, 
>> +      METH_VARARGS, "\n"
>> +      "Dump of a domain.\n"
>
>The description sof domain_dumpcore vs domain_dump above
>are somewhat ambigious. Could you make it clearer what
>the difference between the two is?
>
>Perhaps:
>         "Crash a domain so that it will dump core\n"
>
Yes, this is also good.

Best Regards,

Akio Takebe


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

Hi, John and Tristan and Everyone

Thank you for your comments.
>Le Jeudi 03 Ao 2006 02:26, John Levon a 馗rit :
>> On Thu, Aug 03, 2006 at 09:18:23AM +0900, Akio Takebe wrote:
>> > This patch is sample patch.
>> > I make "xm dump" command with dom0_ops.
>> > xc_domain_dump() only call __domain_crash().
>>
>> It would be /much/ more useful to be able to make it dump without
taking
>> down the domain (just pause it, take the crash dump, then let it
>> continue).
>Yes, I think so too.
>Akio you have implemented ''xm crash''!  But the feature is
useful too.
>
Yes, Live dump feature is also useful.
My "xm dump" is "xm crash" as Tristan said.
I think it is better that we make both live dump and panic dump option.

How about the below?

e.g.
In the case of live dump
  xm dump -l domU
  
  For example, live dump option is used when domU kernel is santy 
  and applications are not sanity.
  
In the case of panic dump 
  xm dump domU or
  xm dump -p domU ( -p is default)
  
  For example panic dump option is used when domU kernel is hungup,
  and we want to reboot and make coredump atomatically.
  
Best Regards,

Akio Takebe


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

Le Jeudi 03 Août 2006 13:10, Akio Takebe a écrit :
> Hi, John and Tristan and Everyone
>
> Thank you for your comments.
>
> >Le Jeudi 03 Ao� 2006 02:26, John Levon a 馗rit :
> >> On Thu, Aug 03, 2006 at 09:18:23AM +0900, Akio Takebe wrote:
> >> > This patch is sample patch.
> >> > I make "xm dump" command with dom0_ops.
> >> > xc_domain_dump() only call __domain_crash().
> >>
> >> It would be /much/ more useful to be able to make it dump without
taking
> >> down the domain (just pause it, take the crash dump, then let it
> >> continue).
> >
> >Yes, I think so too.
> >Akio you have implemented ''xm crash''!  But the
feature is useful too.
>
> Yes, Live dump feature is also useful.
> My "xm dump" is "xm crash" as Tristan said.
> I think it is better that we make both live dump and panic dump option.
>
> How about the below?
>
> e.g.
> In the case of live dump
>   xm dump -l domU
>
>   For example, live dump option is used when domU kernel is santy
>   and applications are not sanity.
>
> In the case of panic dump
>   xm dump domU or
>   xm dump -p domU ( -p is default)
>
>   For example panic dump option is used when domU kernel is hungup,
>   and we want to reboot and make coredump atomatically.
I''d prefer ''xm crash'' (or ''xm
panic'') and ''xm dump'' .
I''d prefer ''xm dump'' *not* to panic by default.  It
is too dangerous.

Tristan.

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

Hi, all
>>   For example panic dump option is used when domU kernel is hungup,
>>   and we want to reboot and make coredump atomatically.
>I''d prefer ''xm crash'' (or ''xm
panic'') and ''xm dump'' .
>I''d prefer ''xm dump'' *not* to panic by default. 
It is too dangerous.
>
OK. I also think both are necessary.
How about the following specification?

1. xm crash
   This is only for crashing a domain.
   If enable-dump is yes, we can get the domain''s core after crash.
   And If we want to atomatically reboot, we should set
on_crash=''restart''
   in domain configuration.
   
2. xm dump
   This is for live dumping a domain.
   This implementation is:
     1. pause the domain
     2. dumping the domain
     3. unpause the domain
     4. reboot (if --noreboot option, don''t reboot)
     
     I think we want to reboot when we want to dump.
     So I want to be default reboot.
     
   BTW, I think the feature to online-dump domain and 
   hypervisor is also necessary.(meaning online is "don''t
pause")
   
Best Regards,

Akio Takebe


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

On Thu, Aug 03, 2006 at 08:10:48PM +0900, Akio Takebe wrote:
>   xm dump -l domU
> In the case of panic dump 
>   xm dump domU or
>   xm dump -p domU ( -p is default)
Please make the "and kill my domain" version not the default -
it''s too
easy to presume that ''dump'' is non-lethal. Or just call it
''crash'' as
suggested.

regards
john

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