On Tue, 2006-10-10 at 07:56 -0600, Khalid Aziz wrote:
> On Tue, 2006-10-10 at 08:44 +0800, Zou, Nanhai wrote:
> > > > I think calling to the fake_rendz code need to be relocated to
> > > > control
> > > page.
> > > > Otherwise there will be problem if kexec into a different kernel. New
> > > > kernel
> > > may overlap to the area of fake_rendz code linked in first kernel.
> > > >
> > > > Thanks
> > > > Zou Nan hai
> > >
> > > Hi Nan hai,
> > >
> > > kexec_fake_sal_rendez is already on control page. Are you suggesting we
> > > move kexec_stop_this_cpu() as well to control page? Theoretically since
> > > we call smp_call_function() with wait=0, it is possible that monarch
> > > might start copying new kernel over before other procesors have had a
> > > chance to process IPI and execute kexec_stop_this_cpu(). In such a case,
> > > there is a possibility kexec_stop_this_cpu() code might be overwritten
> > > with something else before execution. The only right way I can think of
> > > to solve this is to establish a handshake between monarch and slave
> > > processors so monarch can ensure all slave processors have stopped
> > > before it starts copying new kernel over. We could instead call
> > > smp_call_function() with wait=1, but that somehow makes me nervous.
> > >
> > > --
> > I mean in smp.c, you call kexec_fake_sal_rendez directly.
> > So even kexec_fake_sal_rendez is also in control page, kernel will still
> > call to the linked in virtual address.
> > Thanks
> > Zou Nan hai
>
> Ah, that. I fixed that in my test kernel, but must have forgotten to
> send a patch out. I will send out a patch.
I had hacked some code in my test kernel to do this and I am trying to
write this code more cleanly. To do this right, I will need a pointer to
kexec_image in kexec_stop_this_cpu(). Since machine_shutdown() is not
not passed a pointer to kexec_image, it is turning out to not be so easy
to make this change. I have two options at this point:
1. Find another way to find the pointer to kexec_image in
kexec_stop_this_cpu(). Any suggestions?
2. Make CONFIG_KEXEC depend upon CONFIG_HOTPLUG_CPU if CONFIG_SMP is set
and delete kexec_fake_sal_rendezvous code.
I am inclined towards going with option 2. It removes extra code that
can potentially be fragile, and this restriction is not unreasonable
IMO. If option 2 sounds reasonable to everyone, I will send out a patch
to implement this.
Any other opinions?
--
Khalid
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
[EMAIL PROTECTED] Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
