RE: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch]Enable "sysrq c" handler for domU coredump)

RE: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch]Enable "sysrq c" handler for domU coredump)

[Graham, Simon]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

Two things:

1. I'm not convinced 'xm crash' is needed - 'xm destroy' will do this
(and if you want
   a dump, do 'xm dump' followed by 'xm destroy')

2. I don't see the point of the --noreboot option on 'xm dump' -- I
think this command
   should simply live-dump the specified domain - as above you can use
other commands
   to cause the domain to restart afterwards.

3. There's no need to pause the domain to dump it - I actually wrote a
little utility
   to live dump a guest (based on xenconsoled and attached) and it seems
to work
   quite nicely! This could easily be morphed into the 'xm dump' command
- it just
   didn't occur to me at the time!

Simon


> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Akio Takebe
> Sent: Thursday, August 03, 2006 8:57 AM
> To: Tristan Gingold; John Levon; Keir Fraser
> Cc: Muli Ben-Yehuda; Horms; Akio Takebe; xen-devel; Kouya Shimura
> Subject: Re: [Patch][RFC] Support "xm dump" (is Re: [Xen-devel] Re:
> [Patch]Enable "sysrq c" handler for domU coredump)
> 
> 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

[-- Attachment #2: xendump.c --]
[-- Type: application/octet-stream, Size: 3409 bytes --]

/*
 *  Copyright (c) 2006 Stratus Technologies, Inc
 *  Copyright (C) International Business Machines  Corp., 2005
 *  Author(s): Simon Graham <simon.graham@stratus.com>
 *  	       Anthony Liguori <aliguori@us.ibm.com>
 *
 *  Xen Dump Utility
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation; under version 2 of the License.
 * 
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 * 
 *  You should have received a copy of the GNU General Public License
 *  along with this program; if not, write to the Free Software
 *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <stdlib.h>
#include <getopt.h>
#include <err.h>
#include <ctype.h>
#include <string.h>

#include "xenctrl.h"
#include "xs.h"

static int find_domain_id_by_name(struct xs_handle *xs_handle, const char *name)
{
	int domain_id=-1, id, i, num;
	char path[80];
	char *domain_name;
    
	char **list = xs_directory(xs_handle, XBT_NULL, "/local/domain", &num);
	if (list == NULL)
		return 0;
    
	for (i=0; i<num; i++) {
		id = strtol(list[i], NULL, 10);
		if (id == 0)
			continue;

		snprintf(path, sizeof(path), "/local/domain/%i/name", id);
		domain_name = xs_read(xs_handle, XBT_NULL, path, NULL);

		if (strcmp(domain_name, name) == 0) 
			domain_id = id;
	}

	return domain_id;
}

static int get_domain_id(const char *value)
{
	int domid;
	struct xs_handle *xs;
	xs = xs_daemon_open_readonly();
	domid = find_domain_id_by_name(xs, value);
	xs_daemon_close(xs);

	return domid;
}

static void dumpDomU(int domid, const char *dumpname)
{
	int xc_handle;
	int rc;

	xc_handle = xc_interface_open();
	if (xc_handle == -1) {
		err(errno, "xc_interface_open()");
	}

	printf("Dumping domain id %d to %s\n",domid,dumpname);

	rc = xc_domain_dumpcore(xc_handle, domid, dumpname);
	if (rc < 0) {
		err(-rc,"failed to dump core");
	}
}

static void usage(const char *program) {
	printf("Usage: %s [options] domain-name dump-path\n"
	       "Dumps specified domain to named file\n"
	       "\n"
	       "  -h, --help       display this help and exit\n"
	       , program);
}

int main(int argc, char **argv)
{
	int domid;
	char *end;
	char *sopt = "h";
	int ch;
	int opt_ind=0;
	struct option lopt[] = {
		{ "help",    0, 0, 'h' },
		{ 0 },

	};
	while((ch = getopt_long(argc, argv, sopt, lopt, &opt_ind)) != -1) {
		switch(ch) {
		case 'h':
			usage(argv[0]);
			exit(0);
			break;
		}
	}
	
	if ((argc - optind) != 2) {
		fprintf(stderr, "Invalid number of arguments\n");
		fprintf(stderr, "Try `%s --help' for more information.\n", 
			argv[0]);
		exit(EINVAL);
	}

	// Did use specify a numeric domid?
	domid = strtol(argv[optind], &end, 10);
	if (end && *end) {
		// no - treat as name instead
		domid = get_domain_id(argv[optind]);

		if (domid < 0) {
			err(EINVAL,"domain not found");
		}
	}

	dumpDomU(domid, argv[optind+1]);

	return 0;
}

/*
 * Local variables:
 *  c-file-style: "linux"
 *  indent-tabs-mode: t
 *  c-indent-level: 8
 *  c-basic-offset: 8
 *  tab-width: 8
 * End:
 */

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

RE: [Patch][RFC] Support "xm dump" (is Re: Re:[Patch]Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

Hi, Simon

>Two things:
>
>1. I'm not convinced 'xm crash' is needed - 'xm destroy' will do this
>(and if you want
>   a dump, do 'xm dump' followed by 'xm destroy')
>
What do you mean?
I think we cannot dump with "xm destroy" now.
"xm destory" only call the following domain_kill().
void domain_kill(struct domain *d)
{
    domain_pause(d);

    if ( test_and_set_bit(_DOMF_dying, &d->domain_flags) )
        return;

    gnttab_release_mappings(d);
    domain_relinquish_resources(d);
    put_domain(d);

    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
}

Will anyone add crash option in "xm destory" in the feature?

>2. I don't see the point of the --noreboot option on 'xm dump' -- I
>think this command
>   should simply live-dump the specified domain - as above you can use
>other commands
>   to cause the domain to restart afterwards.
>
Ordinary dump features have atomatically rebooting features.
(e.g. diskdump, kdump, and so on)
So I think this is necessary.

>3. There's no need to pause the domain to dump it - I actually wrote a
>little utility
>   to live dump a guest (based on xenconsoled and attached) and it seems
>to work
>   quite nicely! This could easily be morphed into the 'xm dump' command
>- it just
>   didn't occur to me at the time!
>
Your xendump command is dump feature without pause.
In the case without pause, domain's memory is modified while dumping. 
I think both w/o and w pause are needed.

Best Regards,

Akio Takebe

Re: [Patch][RFC] Support "xm dump" (is Re: Re:[Patch]Enable "sysrq c" handler for domU coredump)

[John Levon]

On Fri, Aug 04, 2006 at 12:24:27AM +0900, Akio Takebe wrote:

> >   quite nicely! This could easily be morphed into the 'xm dump' command
> >- it just
> >   didn't occur to me at the time!
> >
> Your xendump command is dump feature without pause.
> In the case without pause, domain's memory is modified while dumping. 
> I think both w/o and w pause are needed.

On the presumption that dumping can take quite a while, I see that not
pausing the domain can be useful. So perhaps:

	xm dump [-Lc] <dom> <filename>

Default: non-destructive, paused dump

-L: live (don't pause the domain)
-c: crash the domain

It should take a filename to dump to...

regards
john

Re: [Patch][RFC] Support "xm dump" (is Re: Re:[Patch]Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

Hi, John

Thank you for your comments.
We're making new patch. 
We'd like to reflect your comments as much as possible.
After post our patch, please review it.
So please wait. :-)

Best Regards,

Akio Takebe

>On Fri, Aug 04, 2006 at 12:24:27AM +0900, Akio Takebe wrote:
>
>> >   quite nicely! This could easily be morphed into the 'xm dump' command
>> >- it just
>> >   didn't occur to me at the time!
>> >
>> Your xendump command is dump feature without pause.
>> In the case without pause, domain's memory is modified while dumping. 
>> I think both w/o and w pause are needed.
>
>On the presumption that dumping can take quite a while, I see that not
>pausing the domain can be useful. So perhaps:
>
>	xm dump [-Lc] <dom> <filename>
>
>Default: non-destructive, paused dump
>
>-L: live (don't pause the domain)
>-c: crash the domain
>
>It should take a filename to dump to...
>
>regards
>john

RE: [Patch][RFC] Support "xm dump" (is Re:Re:[Patch]Enable"sysrq c" handler for domU coredump)

[Graham, Simon]

> BTW, I try to make your xendump.c, but cannot compile it.
> Could you post the Makefile?
> I'd like to use your xendump.

I actually build this out of tree along with some other utilities so the
Makefile wont be a lot of use to you. However, the
relevant sections (mostly taken from tools/console/Makefile btw) are
attached.

Having said that, if you are going to add an 'xm dump' command, I think
it should be done by modifying the xend Python code
rather than building an external C program (I wish I'd thought of this!)

Simon

------Makefile extract------

XEN_ROOT=<path to top of xen tree>

include $(XEN_ROOT)/tools/Rules.mk

CFLAGS  += -Werror -g
CFLAGS  += -I $(XEN_XC)
CFLAGS  += -I $(XEN_LIBXC)
CFLAGS  += -I $(XEN_XENSTORE)
LDFLAGS += -L $(XEN_LIBXC)
LDFLAGS += -L $(XEN_XENSTORE)

BIN = xendump

.PHONY: build

build: $(BIN)

%: %.c
	$(CC) $(CFLAGS) $(LDFLAGS) -lxenctrl -l xenstore -o $@ $<

RE: [Patch][RFC] Support "xm dump" (is Re: Re:[Patch]Enable "sysrq c" handler for domU coredump)

[Graham, Simon]

> Hi, Simon
> 
> >Two things:
> >
> >1. I'm not convinced 'xm crash' is needed - 'xm destroy' will do this
> >(and if you want
> >   a dump, do 'xm dump' followed by 'xm destroy')
> >
> What do you mean?
> I think we cannot dump with "xm destroy" now.
> "xm destory" only call the following domain_kill().

I mean that if you want to crash a domain and collect a dump, you can do
'xm dump' followed by 'xm destroy' or 'xm reboot' -- there's no need to 
add another command to do the combination.

> >2. I don't see the point of the --noreboot option on 'xm dump' -- I
> >think this command
> >   should simply live-dump the specified domain - as above you can
use
> >other commands
> >   to cause the domain to restart afterwards.
> >
> Ordinary dump features have atomatically rebooting features.
> (e.g. diskdump, kdump, and so on)
> So I think this is necessary.

xm dump foo
xm reboot foo

does the job nicely -- why complicate things by adding extra
options/commands

> 
> >3. There's no need to pause the domain to dump it - I actually wrote
a
> >little utility
> >   to live dump a guest (based on xenconsoled and attached) and it
> seems
> >to work
> >   quite nicely! This could easily be morphed into the 'xm dump'
> command
> >- it just
> >   didn't occur to me at the time!
> >
> Your xendump command is dump feature without pause.
> In the case without pause, domain's memory is modified while dumping.
> I think both w/o and w pause are needed.

Hmm... perhaps although I'm not convinced -- I understand that memory
can change during the dump and therefore there can be some
inconsistencies in the dump, HOWEVER, pausing the domain doesn't ensure
all the data structures are consistent either - it pretty much just
stops the VM wherever is happens to be so the memory can still be
inconsistent. 

I also think there is an issue with pausing -- unless I am mistaken,
pause requires code to run in the domain - if the domain is glued up
this cant run and the pause will hang (and lets face it, the usual
reason for dumping a domain is because something is wrong; definitely a
good idea to minimize the amount of work you expect from the domain in
this case).

FWIW, my opinion is that it isn't necessary to pause.

/simgr

RE: [Patch][RFC] Support "xm dump" (is Re:Re:[Patch]Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

Hi, Simon

>I mean that if you want to crash a domain and collect a dump, you can do
>'xm dump' followed by 'xm destroy' or 'xm reboot' -- there's no need to 
>add another command to do the combination.
OK, I understand.

>> >2. I don't see the point of the --noreboot option on 'xm dump' -- I
>> >think this command
>> >   should simply live-dump the specified domain - as above you can
>use
>> >other commands
>> >   to cause the domain to restart afterwards.
>> >
>> Ordinary dump features have atomatically rebooting features.
>> (e.g. diskdump, kdump, and so on)
>> So I think this is necessary.
>
>xm dump foo
>xm reboot foo
OK.

>
>does the job nicely -- why complicate things by adding extra
>options/commands
>
>> 
>> >3. There's no need to pause the domain to dump it - I actually wrote
>a
>> >little utility
>> >   to live dump a guest (based on xenconsoled and attached) and it
>> seems
>> >to work
>> >   quite nicely! This could easily be morphed into the 'xm dump'
>> command
>> >- it just
>> >   didn't occur to me at the time!
>> >
>> Your xendump command is dump feature without pause.
>> In the case without pause, domain's memory is modified while dumping.
>> I think both w/o and w pause are needed.
>
>Hmm... perhaps although I'm not convinced -- I understand that memory
>can change during the dump and therefore there can be some
>inconsistencies in the dump, HOWEVER, pausing the domain doesn't ensure
>all the data structures are consistent either - it pretty much just
>stops the VM wherever is happens to be so the memory can still be
>inconsistent. 
>
>I also think there is an issue with pausing -- unless I am mistaken,
>pause requires code to run in the domain - if the domain is glued up
>this cant run and the pause will hang (and lets face it, the usual
>reason for dumping a domain is because something is wrong; definitely a
>good idea to minimize the amount of work you expect from the domain in
>this case).
>
>FWIW, my opinion is that it isn't necessary to pause.
>
I don't agree it. It is necessary to pause for dumping domU's core,
because debugging is difficut with the unpause core.

But I think we can resolve the issue with the following way.
- If we want to get dump with pause
  1. xm pause foo
  2. xm dump foo
  3. xm reboot foo (if want to reboot)

- If we want to get live dump w/o pause
  1. xm dump foo

BTW, I try to make your xendump.c, but cannot compile it.
Could you post the Makefile?
I'd like to use your xendump.

Best Regards,

Akio Takebe

RE: [Patch][RFC] Support "xm dump" (is Re:Re:[Patch]Enable "sysrq c" handler for domU coredump)

[Harry Butterworth]

FWIW, it occurred to me that if you wanted to test whether a domain
could correctly restart after a power failure it might be convenient to
be able to dump and reboot in one atomic operation such that the dump
captured the state of the system exactly as it was when it went down.

This would make it easier to debug any problems discovered after the
subsequent reboot.

I don't know whether this use-case is significant enough for you to want
to take it into account.

On Fri, 2006-08-04 at 18:58 +0900, Akio Takebe wrote:
> Hi, Simon
> 
> >I mean that if you want to crash a domain and collect a dump, you can do
> >'xm dump' followed by 'xm destroy' or 'xm reboot' -- there's no need to 
> >add another command to do the combination.
> OK, I understand.
> 
> >> >2. I don't see the point of the --noreboot option on 'xm dump' -- I
> >> >think this command
> >> >   should simply live-dump the specified domain - as above you can
> >use
> >> >other commands
> >> >   to cause the domain to restart afterwards.
> >> >
> >> Ordinary dump features have atomatically rebooting features.
> >> (e.g. diskdump, kdump, and so on)
> >> So I think this is necessary.
> >
> >xm dump foo
> >xm reboot foo
> OK.
> 
> >
> >does the job nicely -- why complicate things by adding extra
> >options/commands
> >
> >> 
> >> >3. There's no need to pause the domain to dump it - I actually wrote
> >a
> >> >little utility
> >> >   to live dump a guest (based on xenconsoled and attached) and it
> >> seems
> >> >to work
> >> >   quite nicely! This could easily be morphed into the 'xm dump'
> >> command
> >> >- it just
> >> >   didn't occur to me at the time!
> >> >
> >> Your xendump command is dump feature without pause.
> >> In the case without pause, domain's memory is modified while dumping.
> >> I think both w/o and w pause are needed.
> >
> >Hmm... perhaps although I'm not convinced -- I understand that memory
> >can change during the dump and therefore there can be some
> >inconsistencies in the dump, HOWEVER, pausing the domain doesn't ensure
> >all the data structures are consistent either - it pretty much just
> >stops the VM wherever is happens to be so the memory can still be
> >inconsistent. 
> >
> >I also think there is an issue with pausing -- unless I am mistaken,
> >pause requires code to run in the domain - if the domain is glued up
> >this cant run and the pause will hang (and lets face it, the usual
> >reason for dumping a domain is because something is wrong; definitely a
> >good idea to minimize the amount of work you expect from the domain in
> >this case).
> >
> >FWIW, my opinion is that it isn't necessary to pause.
> >
> I don't agree it. It is necessary to pause for dumping domU's core,
> because debugging is difficut with the unpause core.
> 
> But I think we can resolve the issue with the following way.
> - If we want to get dump with pause
>   1. xm pause foo
>   2. xm dump foo
>   3. xm reboot foo (if want to reboot)
> 
> - If we want to get live dump w/o pause
>   1. xm dump foo
> 
> BTW, I try to make your xendump.c, but cannot compile it.
> Could you post the Makefile?
> I'd like to use your xendump.
> 
> Best Regards,
> 
> Akio Takebe
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: [Patch] Enable "sysrq c" handler for domU coredump

[Horms]

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/

Re: [Patch] Enable "sysrq c" handler for domU coredump

[Akio Takebe]

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

[Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 681 bytes --]

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

[-- Attachment #2: xm_dump.patch --]
[-- Type: application/octet-stream, Size: 7992 bytes --]

# 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.
+ *
+ * @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"
+      " 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;
 };

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[John Levon]

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

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Tristan Gingold]

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.

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

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

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Tristan Gingold]

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.

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

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

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[John Levon]

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

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Horms]

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/

Re: [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump)

[Akio Takebe]

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