On Wed, Jul 24, 2013 at 05:01:39PM +0200, Torsten Kaiser wrote:
> init_amd() will fill that field. (You could alway compile with
> CONFIG_MICROCODE_AMD=n and that field would still need filling)
> And as that will get called before smp_store_(boo)_cpu_info()
> everything should be fine.
Ah yes, I
On Wed, Jul 24, 2013 at 04:44:45PM +0200, Torsten Kaiser wrote:
> Then it would probably be the best to kill free_cache() completely.
> Which would mean cleanup() should also go.
> Which will make unloading microcode_amd.ko impossible.
> But that is probably a good idea anyway: If you unload the mo
On Wed, Jul 24, 2013 at 04:20:58PM +0200, Torsten Kaiser wrote:
> First moving that hunk, then switching from cpu to x86family did work.
> See patch 4/5 and 5/5. :-)
I will get to those eventually.
> > No, we load the microcode based on CPUID(1).EAX which is in the
> > equivalence table. Look at
On Wed, Jul 24, 2013 at 4:19 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
>> > The other problem I see is not updating c->microcode since it is going
>> > to be overwritten by smp_store_cpu_info, which is unfortunate.
>> >
>> > And I don't see where
On Wed, Jul 24, 2013 at 3:56 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
>> >> * Save the amd_bsp_mpb on apply, not on load. Otherwise someone could
>> >> later load an older microcode file that would overwrite amd_bsp_mpb,
>> >> but would not be ap
On Wed, Jul 24, 2013 at 3:41 PM, Borislav Petkov wrote:
> Let me try to answer this as well as I can, peacemeal-wise.
>
> On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
>> On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
>> > On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torst
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> > The other problem I see is not updating c->microcode since it is going
> > to be overwritten by smp_store_cpu_info, which is unfortunate.
> >
> > And I don't see where Intel are updating that cpuinfo_x86.microcode
> > field on earl
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> >> * Save the amd_bsp_mpb on every update. Otherwise someone could offline
> >> the BSP, update the microcode and this would be lost on resume
> >
> > Huh, is amd_bsp_mpb going to disappear all of a sudden?
> >
> > And that doesn't m
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> >> * Save the amd_bsp_mpb on apply, not on load. Otherwise someone could
> >> later load an older microcode file that would overwrite amd_bsp_mpb,
> >> but would not be applied to the CPUs
> >
> > See the patch id check in apply_ucod
Let me try to answer this as well as I can, peacemeal-wise.
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
> > On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
> >> Fixup the early AMD microcode loading.
> >
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
>> Fixup the early AMD microcode loading.
>>
>> * load_microcode_amd() (and the helper its using) should not have an
>> cpu parameter.
>
> Hmm, I don't think so - we get the cp
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
>> Fixup the early AMD microcode loading.
>>
>> * load_microcode_amd() (and the helper its using) should not have an
>> cpu parameter.
>
> Hmm, I don't think so - we get the cp
On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
> Fixup the early AMD microcode loading.
>
> * load_microcode_amd() (and the helper its using) should not have an
> cpu parameter.
Hmm, I don't think so - we get the cpu handed down from microcode_core
and besides the early load on 3
On Tue, Jul 23, 2013 at 05:02:28AM -0700, H. Peter Anvin wrote:
> Borislav, do you agree with these patches? (This one and the errata
> check?) If so I will queue them up in x86/urgent.
I was just about to have another look at the whole deal. Give me a
couple of days - I'll let you know.
Thanks
Borislav, do you agree with these patches? (This one and the errata
check?) If so I will queue them up in x86/urgent.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger
Fixup the early AMD microcode loading.
* load_microcode_amd() (and the helper its using) should not have an
cpu parameter. The microcode loading is not depending on the CPU it is
executed and all the loaded patches will end up in a global list for all
CPUs anyway.
* Return -1 (like Intels apply_mi
16 matches
Mail list logo
