On Wed, Aug 13, 2008 at 10:32:14PM -0700, Mike Shapiro wrote: > The logistics of bundling those userland binaries with the dump > are complex because you have to do it at dump time, not at savecore time. > > Fundamentally though if the interface boundary is truly evolving > that rapidly you do need the self-extracting property in some fashion. > > My personal view is that it would make more sense to have the xVM > kernel emit a dump of a guest VM in the extant canonical savecore > format, keeping its virtual memory implementation details to itself. > Fundamentally our dump format is simply a hash table of VA -> PFN > mappings. It would make more sense to have the panicking dom0
I think you mean 'domU' here. > contain the notion of how to emit its address spaces including those > of guest VMs in that canonical format, and then libkvm would just > work as is, and you would not have this continous revision problem. The problem is *not* the dump format, that's relatively stable, and relatively easy to accomodate. Furthermore, we can't change it as this is what the wider Xen community is using. Nor can we involve the domU in any domain dump step: the ability to get a dump of a totally hung domU has already proven critical in our ability to debug problems both in Xen domUs and with wider Solaris problems[1]. The problem is more fundamental: kernel changes in things like kmem, HAT structures etc. mean that existing mdb dcmds are tied to specific kernel revisions. As Greg mentioned, using mdb_ctf_mumble() will help here, but it's really a matter of policy: should future changes be careful not to break older crash dump processing, or do I have to go through the horror of an mdb_kb backport? To my mind, maintaining some level of compatibility is useful in itself. mdb.eng's mdb wrapper notwithstanding, it can still be troublesome. regards john [1] it's pretty useful for debugging kmdb for one!
