AW: Re: __setup_cpu_be problem

[Benjamin Herrenschmidt]

On Wed, 2006-02-15 at 06:29 -0500, Jimi Xenidis wrote:
> It is important we consider the cases where the hypervisor is present  
> and not present.
> There is also the problem of different Hypervisors.
> I do not think FW without Hypervisor has any  business choosing the  
> page sizes for an OS.
> For Hypervisor machines, as discussed below, it needs to be negotiated.
> There are plenty of things that need to be negotiated like this, and  
> it is likely that each hypervisor will do this differently.

Page sizes are normally not "chosen" in that the architecture was
written with the intend that a given CPU model supports a given range of
page sizes and that gets exposed via the device-tree.

What is causing the current "situation" is that Cell was designed
slightly differently :) It supports 2 large page sizes encodings but 3
actual large page sizes. The matching of one of the encodings to one of
the large page page sizes is done in software via HID6. This doesn't
quite fit in anything that has been defined by our firmware stuff, thus
my initial idea to try to have Cell based firmwares pick the encodings
that make sense for linux, populate the device-tree accordingly and
forget about it (that is 64k and 16M). However, I suppose there might be
applications where 1M makes sense, non-linux OSes or even future
versions of linux that get "fixed" to handle 1M large pages....

Thus if we want that configurable, the question is "where".

I'm not too fan of having yet another mecanism for detecting page sizes
in the hash code though. I'd really like that we stick to the current
mecanism via the device-tree. Thus if we want a way to select the page
sizes on CPUs like Cell, it should be done before we retreive the
device-tree from OF, so that the firmware, when instructed to change it,
can appropriately update the device-tree properties.

The simple way I think is an nvram OF option in /options, along with
other OF environment variables. The more complicated way would be a
specific OF or rtas call (i'd rather avoid HV calls from prom_init but
if we have to ...).

Ben.