[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEAD5592@SHSMSX101.ccr.corp.intel.com>
Date: Wed, 15 May 2013 16:10:37 +0000
From: "Wei, Gang" <gang.wei@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>,
"Ren, Qiaowei" <qiaowei.ren@...el.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tboot-devel@...ts.sourceforge.net"
<tboot-devel@...ts.sourceforge.net>,
"Wei, Gang" <gang.wei@...el.com>
Subject: RE: [PATCH] x86: add a new SMP bring up way for tboot case
Oh, the question should be in what states all the AP CPU registers are. Do you
think we need to define the case like what Intel SDM defined for
getsec[SENTER]?
Jimmy
H. Peter Anvin wrote on 2013-05-15:
> No, this does not really answer the question of what the CPU state looks
> like.
>
> "Ren, Qiaowei" <qiaowei.ren@...el.com> wrote:
>
>> On 2013-05-14, H. Peter Anvin wrote:
>>> On 05/14/2013 02:21 PM, Qiaowei Ren wrote:
>>>> tboot provides a better AP wakeup mechanism based on cpu MWAIT
>>>> feature for OS/VMM. With this mechanism, system will boot faster and
>>>> will NOT require VT to be enabled. But it requires that OS/VMM must
>>>> have support it, otherwise system can never boot up.
>>>>
>>>> Once this mechanism is enabled, tboot will put APs waiting in MWAIT
>>>> loops before launching kernel. kernel can check the new flag field
>>>> in
>>>> v6 tboot shared page for the hint. If the bit
>>>> TB_FLAG_AP_WAKE_SUPPORT in flag field is set, kernel BSP has to
>>>> write the monitored memory
>>>> (tboot->ap_wake_trigger) to bring APs out of MWAIT loops. The sipi
>>>> vector should be written in
>>>> tboot->ap_wake_addr before waking up APs.
>>>>
>>>
>>> This really needs a *detailed* specification about the state the CPU
>>> is parked in. Most BIOSes do in fact park the CPUs in an mwait loop,
>>> but we can't use it because the CPU state they are parked in is
>>> ill-defined.
>>>
>>> This is a good idea, but please write (or point to) a spec about what
>>> the parked CPU state looks like and how the OS gets control. From the
>>> *looks* of the code I assume it is entered in 16-bit real mode but
>>> then it is important to know what parts of the register state are
>> well-defined.
>>
>> The following is how to do mwait for tboot & kernel:
>>
>> For bootstrap processor (BSP), "tboot TXT pre-launch" is executed after
>> BIOS. In this stage, tboot will issue GETSEC[SENTER], which broadcasts
>> messages to the chipset and other physical or logical processors in the
>> platform. In response, other logical processors perform basic cleanup
>> and other tasks, and then finally enter SENTER sleep state.
>>
>> Next, for BSP, SINIT will run and then enter "tboot post-launch", which
>> will start all sleeping APs. If tboot command line option "
>> ap_wake_mwait=true" is set, APs will do some work and then enter mwait
>> loop. Kernel will be launched in BSP by tboot post-launch, and bring
>> APs out of mwait loop.
>>
>> Tboot works in protected mode (but paging is disabled), and closes
>> interrupt. For APs, MONITOR and MWAIT related code in tboot is as
>> follows:
>> while ( _tboot_shared.ap_wake_trigger != cpuid ) {
>> cpu_monitor(&_tboot_shared.ap_wake_trigger, 0, 0);
>> mb();
>> if ( _tboot_shared.ap_wake_trigger == cpuid )
>> break;
>> cpu_mwait(0, 0);
>> }
>> Their extension and hint are all 0. According Intel manual:
>> Extension=0: Treat interrupts as break events even if masked (e.g.,
>> even if EFLAGS.IF=0).
>> Hint=0: the preferred optimized state the processor should enter is
>> C0.
>> So, when "tboot->ap_wake_trigger" is set by kernel, APs can exit from
>> mwait loop.
>>
>> Peter, I don't know whether I explain your problem. What do you think
>> about it?
>>
>> Thanks,
>> Qiaowei
>
Jimmy
Download attachment "smime.p7s" of type "application/pkcs7-signature" (8586 bytes)
Powered by blists - more mailing lists