All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Stekloff <dsteklof@us.ibm.com>
To: Kip Macy <kmacy@fsmware.com>
Cc: Mark Williamson <maw48@cl.cam.ac.uk>,
	xen-devel@lists.sourceforge.net, Chotu Ram <chotwo@hotmail.com>
Subject: Re: xm pause <domain>
Date: Mon, 24 Jan 2005 14:51:50 -0800	[thread overview]
Message-ID: <1106607109.5829.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20050123152519.C63308@demos.bsdclusters.com>

On Sun, 2005-01-23 at 15:34, Kip Macy wrote:
> > Cool!
> 
> Enthusiasm is always welcome  :-).
> 
> >
> > Some information here:
> > http://lkcd.sourceforge.net/doc/linuxworld2000/LKCD.html
> >
> > There may be some more hanging around somewhere - I suspect that's the paper I
> > remembered reading...
> >
> > Of course, for non-Linux guests these tools won't necessarily be much (any?)
> > use, so ELF format core files might prove more generally useful (I don't know
> > if the LKCD lcrash tool can support ELF dump files - it'd be real nice if it
> > did).
> 
> Having worked _briefly_ with elf coredumps as a starting point for
> process checkpointing, I don't think they would be well suited for this.
> An elf coredump defines all of a running applications mappings in the
> program header. In a VM, there will be MANY mappings, which may be
> fragmented, corresponding to many page directory pointers. If all I
> cared about were the kernel state, that would be fine, but I think users
> would like to be able to see what processes were doing at the time.
> Examining the user-state will of course be very OS-specific.
> Nonetheless, I think that it is important that the information be there,
> so that if someone does choose to develop the tool, the pieces will
> already be there.
> 
> Any corrections or contrary opinions are welcome ...


Hi!

Wouldn't ELF header based dump files, like those used for netdump or
diskdump, be useful because you could use gdb to read them? Isn't the
kexec/kdump project doing something in this area? Since kexec/kdump has
quite a bit of backing, wouldn't it be helpful to dump something in the
same format so a single tool like crash could read vmcores dumped by
either method? 

I haven't had the chance to look this up yet, but does a crashdump done
through Xen require the dumping OS to help with the dump? Or, does the
hypervisor do it alone? Obviously, if the hypervisor can do it alone, it
would be better to just have crashdumps with Xen rather than requiring
kexec and invoking another kernel. If, however, the dumping OS is
required to perform the dump through Xen, then kdump may be the best way
to go. 

I'm interested in this area and would like to offer my help testing,
developing, etc. I will definitely look into how the dump is done using
Xen to start. Please let me know if I can help.

Thanks,

Dan



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

  parent reply	other threads:[~2005-01-24 22:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-21 15:14 xm pause <domain> Chotu Ram
2005-01-23 14:41 ` Mark Williamson
2005-01-23 23:09   ` Kip Macy
2005-01-23 23:14     ` Mark Williamson
2005-01-23 23:34       ` Kip Macy
2005-01-24  0:46         ` Mark Williamson
2005-01-26  2:56           ` Kip Macy
2005-01-26 16:23             ` Mark A. Williamson
2005-01-26 16:47               ` Rolf Neugebauer
2005-01-26 17:02                 ` Kip Macy
2005-01-26 19:57                 ` Mark Williamson
2005-01-24 22:51         ` Daniel Stekloff [this message]
2005-01-25 13:46           ` Mark Williamson

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=1106607109.5829.13.camel@localhost.localdomain \
    --to=dsteklof@us.ibm.com \
    --cc=chotwo@hotmail.com \
    --cc=kmacy@fsmware.com \
    --cc=maw48@cl.cam.ac.uk \
    --cc=xen-devel@lists.sourceforge.net \
    /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.