re: potential hack/workaround for cpuinfo not being setup early

[matthew green <mrg%eterna.com.au@localhost>]

   On Sun, Aug 17, 2008 at 06:30:25AM +1000, matthew green wrote:
   > i found this lying around in my tree.  can someone try it out and
   > commit it if it is useful?
   
   I think this is dangerous, as other parts of the kernel think they 
initialized
   everything for all cpus, but actually didn't.

yeah, i've considered that in the past.  that's part of the reason
for this post i made to tech-kern a while back, asking about cpus
being attached "later" in the boot process.  think hot-swap cpus,
or something.  our sparc case isn't really any different from what
the future will hold.
   
   I was just looking at a real solution for this, and while it is not exactly
   straightforward, I think I'm halfay through.

OK.  feel free to ignore my idea :)
   
   However, I do not have the slightest understanding of pre-v9 MMUs, so I can
   only rearange the code to do as close as possible as the old code. I ran
   into a significant difference from the (much more simple) sparc64 code:
   
   The cpu infos are not only page aligned, but cache congruent to the fixed
   CPUINFO_VA. On sparc64 this is not done, but we map the CPUINFO_VA view
   of the page uncached (and wonder off into the real VA imediately if not
   in assembler code - long term I'd like to get rid of the whole fixed mapping
   and use %g7 for curcpu() instead).
   
   So stupid question: wouldn't it be possible to do the CPUINFO_VA page
   uncached on sparc too? This would greatly simplify the code I'm adding to
   pmap_bootstrap. Am I missing something?

unfortunately, i don't know how to answer that one.


pk?