> This is good work!
> It is very necessary for debugging hypervisor or domain0.
> Mark, what do you think about this kdump implementation?
I think kdump, in general, is a nifty solution for supporting crashdumps,
since using a separate kernel for crashdumps gives you the best possible
opportunity to complete them successfully.
Integrating with the Linux crashdump infrastructure seems like a good idea.
It doesn't stop other dom0 OSes using their own crashdump infrastructure, but
with kdump we have a chance of getting a dump even if Xen itself crashes
(whilst admittedly rare, such crashes are something you'd want to get
So, essentially, I think the idea is good - I'll try and take a look through
> Best Regards,
> Akio Takebe
> >On Wed, Apr 12, 2006 at 06:12:30PM +0900, Horms wrote:
> >> kexec: framework and i386
> >> * This patch was prepared against xen-unstable.hg 9514
> >> As of today (9574) two new hypercalls have been added.
> >> I rediffed and moved the kexec hypercall to 33. However
> >> this exceedes hypercall_NR, which is currently 32.
> >> I tried increasing this, but the dom0 now crashes
> >> in entry.S on init. Even after rebuilding both xen and the kernel
> >> completely from scratch after a make distclean. Help!!
> >I am a bit concerned that this patch is going to start rotting if I
> >can't at least track the current xen-unstable.hg, or better still get it
> >I would really appreciate it if someone could take moments to comment on
> >the hypercall problem. Is adding a new hypercall, as the current patch
> >does, the best way? If so could someone point me to how to increase the
> >hypercall table size. If not, is it best to piggyback of the dom0_op
> >hypercall? Or is there some other prefered option?
> >Xen-devel mailing list
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
Xen-devel mailing list