> -----Original Message----- > From: Khalid Aziz [mailto:[EMAIL PROTECTED] > Sent: 2006年10月10日 6:42 > To: Zou, Nanhai > Cc: Horms; Fastboot mailing list > Subject: RE: [Fastboot] kexec_fake_sal_rendez broken? > > On Sun, 2006-10-08 at 10:13 +0800, Zou, Nanhai wrote: > > > -----Original Message----- > > > From: Khalid Aziz [mailto:[EMAIL PROTECTED] > > > Sent: 2006年10月2日 23:33 > > > To: Horms > > > Cc: Zou, Nanhai; Fastboot mailing list > > > Subject: Re: [Fastboot] kexec_fake_sal_rendez broken? > > > > > > On Mon, 2006-10-02 at 17:29 +0900, Horms wrote: > > > > Hi Nanhai, > > > > > > > > I have been looking a little into kexec_fake_sal_rendez, > > > > as I think that kexec for xen will need to use it as I don't > > > > believe that any CPU hotplug infastructure is present there. > > > > > > > > Unfortunately, when compile linux without CPU hotplug support - > > > > thus forcing the kexec_fake_sal_rendez method of shutting down CPUs > > > > to be used - kexec no longer functions unless I set maxcpus=1 when > > > > kexecing into the second kernel. > > > > > > > > Is this a problem that you are aware of? > > > > Do you have any idea where I should poke around to fix it? > > > > > > > > > > That code has not caused problems on single cpu machine in the past. I > > > will take a look. > > > > > > > > > Hi Aziz, > > 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
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
