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
|
Home