AW: Re: __setup_cpu_be problem

[Geoff Levand]

Hollis Blanchard wrote:
> On Tue, 14 Feb 2006 17:25:47 -0600, "Olof Johansson" <olof at lixom.net>
> said:
>> On Tue, Feb 14, 2006 at 03:14:47PM -0800, Geoff Levand wrote:
>> > I guess what I am thinking of are cases like when the firmware has no
>> > clue and just uses defaults, or when the firmware or hypervisor
>> > expect the kernel to set what sizes work best for it.  In these
>> > cases a change needs to be initiated by the kernel.
>> 
>> But then give the firmware a clue, and fix it. For the partitioned
>> case, I'm sure you have ways for an alpha partition to define the
>> characteristics of a guest partition, and/or a small controller image
>> running in your hypervisor for similar purposes.
>> 
>> If the kernel needs to set "what works best for it", then you should
>> look into some of the ELF header flag stuff that IBM pSeries firmware
>> architects seems to love these days, it seems to be the preferred way
>> for the OS to tell firmware/hypervisor what it wants.
> 
> The solution used with the IBM pSeries hypervisor (look for "fake_elf"
> in prom_init.c, in particular the "rpa_note" part of it) is considered
> poor by some kernel developers. Implementing something more
> fine-grained, like a "capabilities" hcall/rtas method/whatever would
> allow for much more flexibility, which makes sense since the information
> we want to communicate will undoubtedly grow on future platforms.

Certainly looks clunky...

> In this case, an hcall requesting two page sizes would allow the
> hypervisor to validate the request and implement it as needed on
> differing hardware, whether it's via HID6 or some other
> hypervisor-privileged mechanism.

That seems a better way.  Do you have any ideas on what other
'capabilities' are or would be desirable?

-Geoff