Re: [Xen-devel] Stability of shared info structs?

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Mon, Jul 31, 2006 at 10:06:04AM +0100, Keir Fraser wrote:

> >Xenstore is only useful on the machine at the time, not more general
> >post-mortem debugging. There needs to be something to allow
> >introspection of domain core dumps in a self-contained manner. If you
> >have a better suggestion for where this might go, then great.
> 
> A fixed pseudophysical address known to your OS and your debugger?

Encoding a special gpfn into our ABI seems very inflexible, and
would mean it's no longer as simple as a kmalloc(). I'd be extremely
concerned about future changes making the known gpfn a problem years
down the line...

We could do a fixed virtual address that we know about and walk from the
vcpu's ctrlregs[3] at least (it looks like this always the kernel cr3 or
good enough), but it still seems better to not have another fixed
address the debugger has to know about.

> no need for changes to core-dump routines.

We'd also like to see further changes to Xen domain core dumps anyway to
help self-identify /what/ it is: thinks like the word size, version[1],
and especially the shared info contents[2], which is often extremely useful
for debugging.

Ideally this would also apply to save files, so we could plug in a
backend to our debugger and magically get debugging of live domains,
cores, and save files. 

regards
john

[1] as it is now, the core file format isn't versioned, unless you go
the route of changing the magic each time

[2] I could be wrong but I don't believe the shared info frame is dumped
into the core

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