From: "H. Peter Anvin" <hpa@zytor.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: Find correct 64 bit ramdisk address for microcode early update
Date: Wed, 11 Jun 2014 10:32:23 -0700 [thread overview]
Message-ID: <539892A7.2030200@zytor.com> (raw)
In-Reply-To: <CAE9FiQX3seRxbotg0OmLFm_WrtY-SoT9uupvZpbAqyur4Hq=aA@mail.gmail.com>
On 06/11/2014 10:30 AM, Yinghai Lu wrote:
> On Tue, Jun 10, 2014 at 11:08 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 06/10/2014 10:04 PM, Yinghai Lu wrote:
>>> When using kexec with 64bit kernel, bzImage and ramdisk could be
>>> loaded above 4G. We need this to get correct ramdisk adress.
>>>
>>> Make get_ramdisk_image() global and use it for early microcode
>>> updating. Also make it to take boot_params pointer for different
>>> usage.
>>>
>>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>>>
>>
>> Have you tested this with early microcode loading on a 32-bit kernel?
>>
>
> No, I did not test that on a 32bit kernel. We did not enabled ramdisk
> loading high
> above 4G, right?
>
> Do you want to me to drop changes for 32 bit path (under those MARCO)?
> like:
> +++ linux-2.6/arch/x86/kernel/cpu/
> microcode/amd_early.c
> @@ -51,12 +51,12 @@ static struct cpio_data __init find_ucod
> */
> p = (struct boot_params *)__pa_nodebug(&boot_params);
> path = (char *)__pa_nodebug(ucode_path);
> - start = (void *)p->hdr.ramdisk_image;
> - size = p->hdr.ramdisk_size;
> + start = (void *)(unsigned long)get_ramdisk_image(p);
> + size = get_ramdisk_size(p);
>
> +++ linux-2.6/arch/x86/kernel/cpu/microcode/intel_early.c
>
> boot_params_p = (struct boot_params *)__pa_nodebug(&boot_params);
> - ramdisk_image = boot_params_p->hdr.ramdisk_
> image;
> - ramdisk_size = boot_params_p->hdr.ramdisk_size;
> + ramdisk_image = get_ramdisk_image(boot_params_p);
> + ramdisk_size = get_ramdisk_size(boot_params_p);
> initrd_start_early = ramdisk_image;
> initrd_end_early = initrd_start_early + ramdisk_size;
>
> BTW, Is there any 32bit bootloader that could load ramdisk above 4G?
>
It is not about loading over 4G, it is that some kinds of code (in
particular accessing global variables) from the early microcode loading
code doesn't work on 32 bits, so it needs to be tested.
-hpa
next prev parent reply other threads:[~2014-06-11 17:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 5:04 [PATCH] x86: Find correct 64 bit ramdisk address for microcode early update Yinghai Lu
2014-06-11 6:08 ` H. Peter Anvin
2014-06-11 17:30 ` Yinghai Lu
2014-06-11 17:32 ` H. Peter Anvin [this message]
2014-06-11 17:34 ` Yinghai Lu
2014-06-12 6:11 ` Yinghai Lu
2014-06-27 23:58 ` H. Peter Anvin
2014-07-01 18:38 ` Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539892A7.2030200@zytor.com \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox