Making IPL coding easier? (fwd)

[Eric W. Biederman]

Ronald G Minnich <rminnich at lanl.gov> writes:

> Neil has a very interesting point, and it does bring up the "cache as ram"
> issue again.
> 
> Neil, my only question is, did you test this MTRR approach on lots of
> CPUs. My impression is that it is not guaranteed to work.

Let me respond.  My apologies for the delay but I misplaced this
email.

There are several sides to this problem.
1) I have tried setting up the MTRRs and fake an area of ram. 
   In fact if you look at the p4dc6 I actually implemented it and
   did a port that way.

   Unfortunately there is not an architecturally garanteed way
   to make this work, and cpu designers are continuously tweaking
   how their caches work so it breaks with new cpus at the drop 
   of a hat.  Especially new hyperthreaded monsters.  
   
   There is no real savings in having code that breaks when new
   cpus are introduced.

2) Using memory that is elsewhere in the system.   I do use
   cmos memory but not currently for temporaries. I like
   the idea.  But with only 128bytes to play with you can not
   do much with it.

3) Using external ram for a stack, is dangerous in a couple
   of ways.  Cache coherency with pci devices isn't garanteed,
   so setting up mttrs over the stack is not guaranteed to work.

   The common case is in processors is to work against cacheable memory.
   I have seen P4's incorrectly execute code when caching was disabled.
   Stacks may soon follow suite.  So long term this does not look
   a solution.

   Then there is the added danger that the device or something on the path
   to the device will be corrupted/broken.  And then you get very strange
   hard to debug failure cases.

The only real solution to this problem is to build a compiler that generates
code that does not use ram.  And then the compiler can have all of the smarts
about how to call subroutines etc.  The coding would still be tricky as you
could not have too many active variables at ounce but it should be much easier
than the current situation.

Eric