lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 4 Jun 2013 15:05:41 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Jacob Shin <jacob.shin@....com>
Cc:	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/microcode] x86, microcode, amd: Fix warnings and errors
 on with CONFIG_MICROCODE=m

On Tue, Jun 4, 2013 at 2:55 PM, Jacob Shin <jacob.shin@....com> wrote:
> On Tue, Jun 04, 2013 at 04:36:00PM -0500, Jacob Shin wrote:
>>
>> It's because the load_ucode_amd_ap() (which is __cpuinit because it
>> can be called during CPU hotplug on).
>
> Sorry, let me clarify. find_ucode_in_initrd() is called by
> load_ucode_amd_ap() during cold boot. However, since
> load_ucode_amd_ap() is also called during suspend/resume (CPU hotplug)
> it has to be __cpuinit. Of course during suspend/resume code path,
> find_ucode_in_initrd() is not called, since it is no longer there in memory.
>
>>
>> Hm.. but yes, I do agree with you, I'm waiting for feedback on this
>> follow up patch to allow multiple concatanated microcode files:
>>
>>   https://lkml.org/lkml/2013/5/31/664
>>
>> I'll submit multi-patch patchset to address your feedback as well.

Those microcode should be with initrd.

During first BP finding and apply it, it is still with initrd that is loaded by
bootloader.

then kernel may move the initrd to mapped range.

then AP will use those moved blob or saved blob during booting path and
hot-add path.

so the find_.._in_initrd should be __init and you just need one pointer
to the blob original or moved.

Thanks

Yinghai
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ