Re: Kexec command line length

[Vivek Goyal <vgoyal@redhat.com>]

On Fri, Jan 25, 2008 at 07:35:58AM -0500, Neil Horman wrote:
> On Tue, Jan 15, 2008 at 12:37:53PM -0500, Vivek Goyal wrote:
> > On Tue, Jan 15, 2008 at 12:09:50PM -0500, Neil Horman wrote:
> > > On Tue, Jan 15, 2008 at 10:27:10AM -0500, Vivek Goyal wrote:
> > > > On Mon, Jan 14, 2008 at 08:43:03AM -0500, Neil Horman wrote:
> > > > > Hey all-
> > > > > 	Regarding this bug:
> > > > > 	http://bugzilla.kernel.org/show_bug.cgi?id=9641
> > > > > 	I'd like to look into putting together a patch for it, and wanted to
> > > > > solicit comments for the best way to go about doing it.  Currently I've got it
> > > > > fixed up in the Red Hat tree by bumping COMMAND_LINE_SIZE to 2048 and
> > > > > eliminating the reserved buffer of the x86_linux_faked_param_header, which works
> > > > > well, but isn't backwards compatible as Bernhard pointed out.  Given that extra
> > > > > constraint, I thought it woudl e best to unify the command line and reserved
> > > > > buffers in x86_linux_faked_param_header to one contiguour 2048 byte block and
> > > > > maintain a separate variable that defines the command line length based on a
> > > > > parsing of the UTS_VERSION.  Does that sound reasonable to everyone, or is there
> > > > > a better way that someone has in mind?
> > > > > 
> > > > 
> > > > Hi Neil,
> > > > 
> > > > Looking at UTS_VERSION and then deciding the command line length seems
> > > > ok. 
> > > > 
> > > > When I look at inclue/asm-x86/bootparam.h in kernel, area starting from
> > > > 0x2d0 to all the way up to 4K has been reserved for e820 maps and EDD buf.
> > > > 
> > > > Does that mean newer boot loaders are putting command line outside of 
> > > > 4K page and only putting the pointer to cmdline in 4K page. If that's the
> > > > case then we might have to do the same for kexec.
> > > > 
> > > 
> > > That would seem to be the case yes, although it appears the kernel still
> > > supports the old boot protocol if you want to restrict the command line length
> > > to the old 256 chars (see copy_boot_data)
> > > 
> > 
> > If that's the case then we probably should not be merging command_line
> > and reserved area. Instead we might have to put command line somewhere
> > else and pass the pointer to it in param page. If command line is with-in
> > 256, then we can continue to pass it in param page. 
> > 
> Actually, Vivek, I take back what I said (at least in part).  Looking at the
> kernel side of this, it seems that the traditional COMMAND_LINE_SIZE has been
> extended as well to 2048 bytes for i386/x86_64.  So unless I'm mistaken (and I
> may be), it looks like we can either:
> 
> a) use the new protocol
> OR
> b) just gobble up the no-longer-existing reserved area which is now used fully
> for command line 
> 
> Clearly the ability to do both would be good, but it would seem my earlier,
> simple approach is workable.  Thoughts?
> 
Hi Neil,

I had a closer look at the code and following are my thoughts.

If I look at the 2.6.24 x86 boot code, I think this code does not expect a
boot loader to put 2048 size command line in 4K page (so called zero page).
I think what it expects is that a boot loader puts command line somewhere
outside the zero page and just pass the pointer to that command line in zero
page.

So far kexec has been putting command line in zero page. I think it worked
because command line was small (256) and zero page had lots of free
reserved area. (E820MAX was 32). 

Now in latest kernel code E820MAX has been increased to 128 and I don't see
lot of free space in bootparam where we can put the 2048 size command line.

If we just continue to do what we are doing and just extend the command
line size to 2048 in kexec-tools, i think this will overlap with some other
area, either with EDD or E820 map etc and real mode code will overwrite part
of command line as passed by kexec, on some systems.

So I think we should modify kexec-tools and start putting the 2048
size command line outside the setup/zero page.

CCing HPA and Eric. They should be able to guide us better.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec