lkml.org 
[lkml]   [2008]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/4] x86: AMD microcode patch loading v2 fixes
2008/7/29 Max Krasnyansky <maxk@qualcomm.com>:
> Dmitry Adamushko wrote:
>>
>> 2008/7/29 Peter Oruba <peter.oruba@amd.com>:
>>>
>>> Fixed coding style issues.
>>
>> I have a comment on the abstraction layer (microcode_ops).
>>
>> [ Not that I've looked very carefully at it so far, nor I pretend to
>> be at-ease with this 'microcode' topic to make any design judgements
>> :-) ]
>>
>> but would it be somehow possible to not have set_cpus_allowed_ptr()
>> code in arch-dependent parts? Let's say the mechanism of how to run
>> certain arch-specific code (and synchronization) on a given cpu should
>> be a prerogative of (and placed in) the generic part...
>>
>> Note, this code will likely happily give you an oops if you run
>> cpu_down/up() ;-)
>>
>> I also wondered, is there a requirement that when a new cpu is brought
>> up, microcode updates {should,must} be done as early as possible, say
>> before any tasks have a chance to run on it? Or can the update be a
>> bit delayed? e.g. we don't do it from cpu-hotplug handlers.
>
> Dmitry looks like you missed my email. I already asked that question and
> proposed a couple of options (workqueue and ipi).
> Tigran said that he does not know. Maybe Peter does.
>
> My guess is that it does not have to be done synchronously and can be
> delayed. There is no guaranty that microcode CPU hotplug handler will run
> before all the other handlers. Which by definition means that some things
> will start running on the cpu before the microcode is updated.

yes.

> Hence we
> might as well do the update outside of the cpu hotplug path.

but it doesn't necessarily mean that it was correct before (I mean,
maybe some assumptions were made about cpu-hotplug handlers :-)



>
> Max
>

--
Best regards,
Dmitry Adamushko


\
 
 \ /
  Last update: 2008-07-29 21:41    [W:0.396 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site