On Thu, Aug 14, 2008 at 02:05:06PM +0100, John Levon wrote: > 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].
I did mean dom0 above: that's what I was referring to, having dom0 emit the dump of a hung domU in the appropriate canonical format. But anyway I guess you're saying that isn't the issue. > 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. That isn't a new problem: that's the same problem that has always existed. This is why mdb modules are separate from mdb itself, and why we have the wrapper script, and the archives of mdb modules. If you're looking at the dump you need the modules from it. The thing that one could do under Xen that one cannot do normally (for reasons I explained to Greg) is that you could bundle archives of modules with dom0 for various versions of Solaris domU, such that when dom0 dumps a domU, it can include them (or simply just have them available on the filesystem for examining those dumps). -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
