[coreboot] [RFC] v3: Stack switching abstraction for C7 and later Intel processors

[Carl-Daniel Hailfinger]

On 14.10.2008 21:10, Marc Jones wrote:
> ron minnich wrote:
>> On Tue, Oct 14, 2008 at 9:31 AM, Marc Jones <Marc.Jones at amd.com> wrote:
>>
>>> Why not ret and do a call (or ljmp) from stage0_main to main(). It
>>> would
>>> make the code easier to follow and it would be easy to add code if
>>> anything
>>> were required between disable car and the jmp.
>>>
>>
>> it's just not doable on  some of these hardware implementations. It's
>> desirable but not doable. There are going to be cases where
>> disable_car resumes somewhere else. So we might as well just get it
>> over with and put it in the code ;-)
>>
>
> What is the hardware limitation? I don't know gcc that well, but a
> lcall wouldn't get the correct address on the stack? If not, what
> about passing the return address(or pushing it on the stack). It is
> more complicated to do but it makes the code easier to understand.

Marc, you assume all hardware is sane.
Returning is not the problem (actually, returning to the caller is easy
to get right). However, gcc is free to access stack slots of the calling
function without going through %esp. If such an access happens, the
caller of disable_car() will access the old stack location (despite the
new %esp) and since that old location isn't backed by RAM/CAR, it will
get garbage. Of course, it would be possible to postprocess the gcc
output to check for such code, but I consider that to be a really
fragile construct which may fail anytime.

> A few other comments from this thread.
>
> > + * returns bottom of stack, when passed an on-stack variable such as a
> > + * parameter or automatic. Stack base must be STACKSIZE aligned
> > + * and STACKSIZE must be a power of 2 for this to work.
> > + * Luckily these rules have always been true.
> >
>
> Also, that was a good catch by Carl-Daniel about that cache stack size
> and alignments. CAR is closely related to MTRRs so I think that the
> MTRR rules should be used here. Or don't have any rules, it is up to
> the caller to get it correct for their CPU.

Thanks! I hope to build something which will meet you approval and be cheap.

How expensive are MTRR readouts? Right now we run bottom_of_stack() once
for every character in a printk(). Having an expensive operation there
would slow down coreboot in an inacceptable manner.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/