[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50AE70E7.6060204@zytor.com>
Date: Thu, 22 Nov 2012 10:37:27 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Yinghai Lu <yinghai@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-kernel@...r.kernel.org, Rob Landley <rob@...dley.net>,
Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCH v3 11/12] x86, boot: add fields to support load bzImage
and ramdisk high
On 11/22/2012 10:28 AM, Yinghai Lu wrote:
>
> has problem with old kexec, it only copy header from bzImage include
> setup_header as boot_param.
>
How old are we talking here? This is a clear and blatant bug, and it
would affect a whole bunch of things, not just this. In fact, one
really has to wonder how it can work at all.
One option I guess would be to have a sentinel field which, if it is not
zero, causes the kernel to zero all of struct setup_info outside of
setup_header... however, I have a nasty suspicion that this kexec botch
might be initializing some fields and leaving others unmodified, which
basically means "there is no hope for sanity and it is just working by
pure accident."
Eric, do you have any insight here?
> looks we only can use [0x30,0x3c), [0x1e8, 0x1f0), but in boot_params, they
> are apm_bios_info, and alt_mem_k...
... which I suspect get set by said kexec botch.
> so looks we still have to use setup_header instead.
We need to dig into this and either say "this is unsupportable" or put
in some kind of hack.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists