Determining CPU features / cache organization from userland

[Joseph Koshy]

Hi Bruce,

A few thoughts on your API:

1) Rather than naming the struct's as "l1", "l2" etc, it may be more
   orthogonal to use an array of cache entries like so

   struct entry { ... } entries[MAX_ENTRIES];  where MAX_ENTRIES would be say, 
8.

2) We could pass information back about whether the cache is write-back or
   write-through and whether it uses write-allocate.  In some CPUs (e.g. 
   the AMD K6-2) this aspect of the cache is programmable at boot time.

3) Have a bit indicating whether the cache is indexed virtually or physically. 

   This allows us to describe TLBs and caches using the same descriptor; the
   MIPS R4K used virtually addressed L1 caches, IIRC.

4) For caches and TLBs that support variable line/page sizes, we would 
   be reporting the currently programmed size (the kernel knows this
   information) I guess?

The 'type' field of the cache descriptor could be an `u_int32_t' or 
`u_int16_t',
allocated out as follows:

	kind:		tlb/cache/other			2 bits
	addressing:	virtual/physical/unknown	2 bits
	mode:		data/instruction/both/unknown	2 bits
	distance:	L0/L1/L2/whatever		3 bits
	on-write-hit:	write-back/write-thru/unknown	2 bits
	on-write-miss:	write-allocate/unknown		2 bits

Another suggestion I have is that the sysctl return:

        int n_entries;
        struct entry entries[n_entries];

since it isn't clear how many levels of cache and how many kinds
of TLBs are going to be used in the systems of tomorrow.

Regards,
Koshy
<jkoshy at freebsd.org>