WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] capturing windows crash dumps

To: "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] capturing windows crash dumps
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Wed, 19 Aug 2009 09:53:54 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 18 Aug 2009 16:54:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.0908181446310.4835@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AEC6C66638C05B468B556EA548C1A77D016DE332@trantor> <C6B058E1.124A8%keir.fraser@xxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D016DE335@trantor> <alpine.DEB.2.00.0908181446310.4835@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcogCjgsnfpBvnV8SYSlr2g7cbOIpQAVDlyw
Thread-topic: [Xen-devel] capturing windows crash dumps
> On Tue, 18 Aug 2009, James Harper wrote:
> > > On 18/08/2009 11:42, "James Harper"
<james.harper@xxxxxxxxxxxxxxxx>
> > wrote:
> > >
> > > >> Could it be as simple as write the guest physical address of a
> > > > pre-allocated
> > > >> buffer into xenstore (from GPLPV drivers)? Then dump that area
of
> > > > guest
> > > >> memory on guest bugcheck, even as a manual operation from dom0?
> > > >
> > > > The memory in question could be anything from 64kb (minidump) to
the
> > > > size of DomU memory (full dump) or somewhere inbetween (kernel
> > dump).
> > > > I'm normally just interested in the kernel dump which is
normally a
> > much
> > > > more respectable size, but still not the size of memory you can
> > easily
> > > > find when the system has gone belly up.
> > >
> > > Hmm, okay. Could you dump it out over the emulated serial line?
> > >
> >
> > I was thinking about that. It could work, then I could just do 'xm
> > console <domu> >dump' and parse the dump from there or something.
> >
> 
> Good idea, also keep in mind that qemu can emulate multiple serials if
> needed.
> Stubdoms support multiple serials too, so if you make the changes to
add
> another serial to qemu please test with stubdoms too :)

How fast do you think that serial port output could be? Is the baud rate
limited by qemu? To put the question another way, the size of the dump
could be up to the size of DomU's memory so could be many gigabytes,
although would typically be <500MB, would that dump out in reasonable
time?

Thinking about it some more, it would be nice to have a mechanism that
could allow PV Linux/BSD/Solaris/etc to dump out similar information in
the event of a complete crash. What would be involved in having a
hypercall that could be called repeatedly to send data to Dom0? 1 page
at a time would be fine, so the parameters could be 'pfn, offset,
length'. I guess the problem wouldn't be in adding the hypercall but in
having the information end up in Dom0... would that be really difficult
and/or messy?

James


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