[coreboot] locking...

[ron minnich]

On Fri, Jun 19, 2009 at 10:49 AM, Stefan Reinauer<stepan at coresystems.de> wrote:
> ron minnich wrote:
>> yes, that is why I did that struct-based stack in my v3 SMP startup.
>>
> So, which problem does this solve, the pre-ram locking or the post-ram
> locking?

it solves the problem of the fact that many people find the v2 smp
startup code unreadable.

>
> - the pre-ram locking can't be done with a stack, because the cache
> between CPUs is not always necessarily in the same state.

well, that may be true on intel stuff. The AMD startup (at least as I
understand it) depends on the BSP memory
being functional enough to provide the APs with a stack.

> -the post-ram code does not need it, works quite nicely already.

actually, this is only partially true. It is still possible for a
malfunctioning AP to lock the BSP out. It's just not something we've
seen much of.

> This approach scares me... it doesn't solve the one case but makes the
> other case much more complex.
>
> Please explain... I must be getting something wrong.

The struct-based stack is a direct copy of the v2 startup. Rather than
using lots of fiddly offsets onto a memory area, it provides a struct
which contains variables and a stack. The variables are shared between
the AP and the BSP. It is a more C-like way to do it.
Once I did it I realized that the on-stack variables could be used as
a communications path from the AP to the BSP, most important one being
a POST variable that could be set by the AP
and monitored by the BSP. This is a bit better than what we have in
v2, where we get one bit back from the AP which tells us "done" or
"not done". No real progress indication
is available. At some point, the BSP times out the AP, but there is no
error code. Plus, the way in which the shared variable is set up in v2
is not very straightforward.

Anyway, I'm OK if we want to stick with what we have, but if we start
hearing more about busting locks, then let's reexamine our
assumptions.

ron