From: Horms <horms@verge.net.au>
To: Akio Takebe <takebe_akio@jp.fujitsu.com>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>,
xen-devel <xen-devel@lists.xensource.com>,
Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Patch] Enable "sysrq c" handler for domU coredump
Date: Tue, 1 Aug 2006 18:26:23 +0900 [thread overview]
Message-ID: <20060801092622.GA28388@verge.net.au> (raw)
In-Reply-To: <50C6B549C9FCF3takebe_akio@jp.fujitsu.com>
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/
next prev parent reply other threads:[~2006-08-01 9:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 3:11 [Patch] Enable "sysrq c" handler for domU coredump Akio Takebe
2006-08-01 3:48 ` Horms
2006-08-01 4:39 ` Akio Takebe
2006-08-01 6:48 ` Horms
2006-08-01 9:06 ` Akio Takebe
2006-08-01 9:26 ` Horms [this message]
2006-08-01 10:33 ` Akio Takebe
2006-08-03 0:18 ` [Patch][RFC] Support "xm dump" (is Re: Re: [Patch] Enable "sysrq c" handler for domU coredump) Akio Takebe
2006-08-03 0:26 ` John Levon
2006-08-03 6:09 ` Tristan Gingold
2006-08-03 11:10 ` Akio Takebe
2006-08-03 11:58 ` Tristan Gingold
2006-08-03 12:57 ` Akio Takebe
2006-08-07 18:04 ` John Levon
2006-08-03 1:50 ` Horms
2006-08-03 11:10 ` Akio Takebe
2006-08-01 8:03 ` [Patch] Enable "sysrq c" handler for domU coredump Keir Fraser
2006-08-01 8:15 ` Muli Ben-Yehuda
2006-08-01 8:12 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060801092622.GA28388@verge.net.au \
--to=horms@verge.net.au \
--cc=kouya@jp.fujitsu.com \
--cc=muli@il.ibm.com \
--cc=takebe_akio@jp.fujitsu.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.