[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: potential hack/workaround for cpuinfo not being setup early
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
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.
Main Index |
Thread Index |