> -----Original Message----- > From: Khalid Aziz [mailto:[EMAIL PROTECTED] > Sent: 2006年10月18日 22:49 > To: Zou, Nanhai > Cc: Fastboot mailing list; Luck, Tony > Subject: Re: [Fastboot] kexec_fake_sal_rendez broken? > > 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? > Yes, I have some other reason to remove them. 1. The control page is not guaranteed to be not used by the second kernel. So if normal kexec(not kdump) from an SMP kernel to an UP kernel, it is possible the second kernel write to those control page.
2. SN platform require put CPU back to true SAL rendez loop to target I/O interrupt, otherwise the second kernel will not boot. Thanks Zou Nan hai > -- > 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
