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: "Paul Durrant" <paul.durrant@xxxxxxxxxx>, "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
Subject: RE: [Xen-devel] capturing windows crash dumps
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Thu, 20 Aug 2009 19:56:18 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 20 Aug 2009 02:56:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A8C025B.7000608@xxxxxxxxxx>
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> <AEC6C66638C05B468B556EA548C1A77D0177CCC1@trantor> <20090819133510.GA26154@xxxxxxxxxxxxxxxxxxx> <4A8C025B.7000608@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acog05FOM9DtAXPlSECLP8nQs0aa2QAp1Mow
Thread-topic: [Xen-devel] capturing windows crash dumps
> > How does Windows natively/normally do its dump? Is it just dumping
the
> > entire memory space
> > on the local disk? Or do you have to set special flags to do so from
the
> > driver?
> 
> Yes, it normally dumps it's memory to the device using a special
> incarnation of the driver stack for that device.
> 

That is correct. An additional and completely separate version of the
driver is created at boot time and only activated in the event of a
crash. The driver is called with all interrupts disabled and cannot
allocate memory etc, so it's a very restricted environment. The ISR is
called on a timer. Hibernate is a separate copy of the driver again but
similar setup.

There are a few callbacks you can set in any driver to tell Windows to
call you every time it has some crash dump information to write out, and
the runtime environment is similar (interrupts disabled, very few system
calls at your disposal). It is this that I would like to use to write
out a crash dump to be captured by Dom0.

The two ideas under consideration are:
1. Use the serial port
2. Create an event channel and a mapped page and dump data out that way.
Add them to the start info page for PV and as HVM parameters (retrieved
via hypercall like the xenstore page and pfn) for HVM

I like #2 best for the following reasons:
. qemu needs patching for a second serial port anyway. I don't want to
use the primary as I'm already using it for something else in the
environment I'm thinking of.
. much more efficient
. works with PV (irrelevant though if there are no PV domains that
support writing out a dump file)
. easy for the DomU to tell if there is something waiting to capture the
crash dump (no parameter present = no crash dump)
. less code on the windows side of things, vs trying to access the
serial port hardware directly for which there is no 'blessed' mechanism
to do in a crash dump environment afaik

James


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