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

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Aug 16, 2008 at 10:44:01PM +0200, Martin Husemann wrote:
> The cpu infos are not only page aligned, but cache congruent to the fixed
> CPUINFO_VA.

Well, after looking closer: at least the above describes what the old
code apparently tries to do, however:

to find the cache size, it uses CACHEINFO.c_totalsize, which is 
cpuinfo.cacheinfo, which is

  (*(struct cpu_info *)CPUINFO_VA).cacheinfo.c_totalsize

but: CPUINFO_VA is only mapped a few lines later. On my machine with 

  cpu0 at mainbus0: mid 8: RT620/625 @ 180 MHz, on-chip FPU
  cpu0: 512K byte write-back, 32 bytes/line, sw flush: cache enabled

the code calculating the alignement for the cpuinfo reads a total
cache size of 0 (so it ends up with simple page alignement).

Fun. Guess I should check the same on a 4.0 kernel now - maybe it never
worked as intended and we could just ignore the alignement.

> 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).

Of course we are lucky there - we map the cpuinfo with 64kB pages, and typical
cache size is 32k instruction/16k data (the external cache should not matter).

Martin