AW: Re: __setup_cpu_be problem
Geoff Levand
geoffrey.levand at am.sony.com
Wed Feb 15 11:22:46 EST 2006
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
More information about the Linuxppc64-dev
mailing list