Thomas De Schampheleire wrote:
> Hi,
>
> 2007/5/23, Bill Holler <Bill.Holler at sun.com>:
>> Thomas De Schampheleire wrote:
>> > Hi,
>> >
>> > In uts/sun4u/os/mach_startup.c, there is a function
>> > mach_cpu_halt_idle() which is called from startup_end() in
>> > uts/sun4u/os/startup.c
>> >
>> > This function has the following contents:
>> >
>> > 385 void
>> > 386 mach_cpu_halt_idle()
>> > 387 {
>> > 388 if (enable_halt_idle_cpus) {
>> > 389 if (&cpu_halt_cpu) {
>> > 390 idle_cpu = cpu_halt;
>> > 391 disp_enq_thread = cpu_wakeup;
>> > 392 }
>> > 393 }
>> > 394 }
>> >
>> > The cpu_halt_cpu() function is only defined for some platforms, in
>> > sun4u the only one I find is "olympus".
>> >
>> > In my research project we are using a full system simulator in which
>> > OpenSolaris runs. I would like to make OpenSolaris believe that
>> > halting is possible by providing my own cpu_halt_cpu() function.
>> >
>> > If I provide such a function in a kernel module, can I then re-call
>> > mach_cpu_halt_idle() in order to overwrite the idle_cpu() and
>> > disp_enq_thread() pointers? Or will this result in panic or incorrect
>> > behavior?
>> >
>> No. mach_cpu_halt_idle() should only be called in system startup
>> before scheduling starts. mach_cpu_halt_idle() was not intended to
>> change the idle_cpu and disp_enq_thread function pointers on the fly.
>>
>> *You could modify cpu_halt() and cpu_wakeup() and your new
>> functions to handle changing on a live system.
>>
>> > If this is not possible from a module, I would like to statically add
>> > this cpu_halt_cpu() to the correct file in uts/sun4u/cpu/ so it is
>> > seen at startup. I don't know which one this would be however. I am
>> > simulating a serengeti machine, but there are no serengeti-specific
>> > files in this directory. Shall I then simply put the code in the
>> > us3_common files?
>> Later Serengeti systems have cheetah processors. Either
>> uts/sun4u/cpu/us3_common* or uts/sun4u/cpu/us3_cheetah* files
>> should work.
>>
>>
>> >
>> > Just to be sure: this halt_cpu mechanism will overwrite the idle loop
>> > so as to halt upon idling, and wakeup when some task has to run,
>> > right? This halting can enable energy savings.
>>
>> Yes. I assume your new implementation will use poke_cpu() to
>> wake up the idle cpus with an Inter Processor Interrupt?
>
> I'm not exactly sure why you assume this and what you mean.
>
> The implementation of cpu_halt_cpu() in olympus is:
> 1923 ENTRY_NP(cpu_halt_cpu)
> 1924 .word 0x81b01040
> 1925 retl
> 1926 nop
> 1927 SET_SIZE(cpu_halt_cpu)
>
> I'm not exactly sure what the .word instruction does (manual says:
> Generates (a sequence of) initialized words in the current segment.),
> but I suppose it is used here to set some value.
.word is used to encode an instruction the assembler does not understand.
In this case .word 0x81b01040 encodes the "suspend instruction".
.word is used when writing assembly code before an updated assembler
has been written. .word is also used when the code will be back-ported
to an earlier OS release that will be assembled by an earlier assembler
that does not understand the newer instruction mnemonic.
> What I planned was to remove that, and inside cpu_halt_cpu() use a so
> called 'magic instruction' that signals a certain condition to the
> simulator, and then simply return.
>
> For the wakeup: I assumed that this would work like it is now, there
> doesn't seem to be a hardware dependent function for that, right?
Hardware dependent wakeup function usually wake up an idle
processor by sending it an inter processor interrupt. They usually use
poke_cpu() to send the interrupt. I assumed USIII processors
supported a halt instruction that idles the pipeline and use IPI to wake
up the processor. However I cannot find hardware dependent
functions for USIII.
Regards,
Bill
> Thomas
>
>>
>> Regards,
>> Bill Holler
>>
>> > Thanks, Thomas
>> > _______________________________________________
>> > tesla-dev mailing list
>> > tesla-dev at opensolaris.org
>> > http://opensolaris.org/mailman/listinfo/tesla-dev
>>
>>
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://opensolaris.org/mailman/listinfo/tesla-dev
