All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akio Takebe <takebe_akio@jp.fujitsu.com>
To: Horms <horms@verge.net.au>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Akio Takebe <takebe_akio@jp.fujitsu.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>
Subject: Re: [Patch] Enable "sysrq c" handler for domU coredump
Date: Tue, 01 Aug 2006 19:33:50 +0900	[thread overview]
Message-ID: <52C6B555FA5977takebe_akio@jp.fujitsu.com> (raw)
In-Reply-To: <20060801092622.GA28388@verge.net.au>

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

  reply	other threads:[~2006-08-01 10:33 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
2006-08-01 10:33           ` Akio Takebe [this message]
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=52C6B555FA5977takebe_akio@jp.fujitsu.com \
    --to=takebe_akio@jp.fujitsu.com \
    --cc=horms@verge.net.au \
    --cc=kouya@jp.fujitsu.com \
    --cc=muli@il.ibm.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.