RE: [PATCH] kexec on ia64

[Zou Nan hai <nanhai.zou@intel.com>]

Hi Khalid,

On Thu, 2005-10-27 at 05:49, Khalid Aziz wrote:
> On Wed, 2005-10-26 at 12:02 -0700, Luck, Tony wrote:
> > > Cool.  Tony, what are your plans for pushing this to Linus?  Will
> it make 
> > > 2.6.15?
> > 
> > Nanhai Zou here at Intel expressed a few concerns to me last night
> > about Khalid's patch.  I'll paste them here to speed discussion
> about
> > this (as I expect Nanhai is asleep at the moment, he should be
> > around to start commenting for himself by 4-5pm Pacific).
> > 
> > > I think his patch is still not able to boot an unmodified kernel.
> > > It appends a kernel parameter to bypass the issue, thus the second
> kernel need to be modified.
> > 
> 
> True. The only time I use this parameter is to determine whether to
> virtualize EFI or not. EFI does not respond well to being virtualized
> once it has been virtualized already. So the kernel needs to know if
> EFI
> has already been virtualized by previous kernel. It is possible to
> pass
> this information to the next kernel as a command line parameter, as I
> have done, or in one of the kexec segments. One way or the other,
> kernel
> needs to know this. I have not found a way around it. If there is one,
> I
> would like to hear about it. That will make enable unmodified kernel
> to
> be booted.
> 
> > > It also hardcoded initrd logic in kernel patch.
> 
> I could not find a better way to pass initrd image to ia64 kernel
> since
> it is not placed in a fixed location. Using a fixed kexec segment
> looked
> fairly logical to me. Alternative would be to add a type field to
> struct
> kexec_segment, then kernel can determine which segment holds initrd
> image without having to use a fixed kexec segment.
> 
> > > Command line is still using old command line.
> 
> Please explain.
> 
  Sorry, I see how your patch can deal with command line. I missed the
machine_kexec_prepare part at the first look. However I prefer to put
command line and initrd logic to kexec tools instead of hack on segment
index.

> > > No purgatory code support etc.
> > 
> > > How, I prefer to put a small and clean patch in kernel while leave
> most of the things in kexec-tools. 
> > > That will provide more flexibility.
> > 
> > > There are also some other issues I can see, like, 
> > > 1. icache flusing miss
> > > 2. rendez code is fake, I prefer to use hotplug API.
> 
> That would be preferable, and would be a good enhancement over current
> code if it can be made to work reliably. I was planning to look into
> it
> after initial implementation (I wrote initial implementation before
> CPU
> hotplug API was available).
> 
> > > 3. Disable PCI master code should be in generic PCI driver code
> instead of IA64 arch code.
> 
> Agreed. This is part of some of the cleanup that can still be done.
> 
> > 
> > Nanhai has his own patches for kexec/kexec-tools, which are
> > stuck in some Intel bureaucracy at the moment ...  I'm trying
> > to get them unstuck so that we can get some meaningful
> > commentary from the community about both versions.
> > 
> > My biggest issue with both patches at the moment is that I
> > can't see how either of them can be extended to be useful
> > for use in crash-dump case without some significant surgery.
> > Both of them over-write the existing kernel with the new one,
> > which is a big problem when you'd like to dump the data space
> > of the old kernel.  Ia64 is quite happy to run a kernel loaded
> > at any suitably aligned address ... so why not load the new
> > kernel in some different location from the old kernel?
> > 
> > Including this in 2.6.15?  It's possible, but it's looking like
> > this might be a rush.  Assuming Linus releases 2.6.14 by the
> > end of this week, we only have a couple of weeks to check that
> > this runs on all of the weird configurations.  I'd need to see
> > a lot of "tested on xxx-config ... no problems" e-mail to get
> > confidence in this.
> > 
> > -Tony
> 
> -- 
> Khalid
> 
	
	As Tony said, I have my kexec and kexec-tools patches
solved those issues. It can boots any unmodified kernel. But they are
pending at Intel bureaucracy.

Hope I can send out them to community for comments soon.

Thanks
Zou Nan hai