Jan Beulich wrote on 2011-12-21: >>>> On 21.12.11 at 12:22, "Wei, Gang" <[email protected]> wrote: >> Without this delay, Xen could not bring APs up while working with >> TXT/tboot, because tboot need some time in APs to handle INIT before >> becoming ready for receiving SIPIs. (this delay was removed as part >> of c/s 23724 by Tim Deegan) >> >> Signed-off-by: Gang Wei <[email protected]> >> >> diff -r d1aefee43af1 xen/arch/x86/smpboot.c >> --- a/xen/arch/x86/smpboot.c Wed Dec 21 18:51:31 2011 +0800 >> +++ b/xen/arch/x86/smpboot.c Wed Dec 21 19:08:57 2011 +0800 >> @@ -463,6 +463,10 @@ static int wakeup_secondary_cpu(int phys >> send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY; >> } while ( send_status && (timeout++ < 1000) ); >> } >> + else >> + { >> + mdelay(10); >> + } > > Does it really need to be this long then (even in the non-TBOOT case)?
No, it could be shorter. I just take a used value back here. If it does matter, we could use a tested working value here: udelay(10), and for tboot case only. Jimmy > > Jan > >> >> /* >> * Should we send STARTUP IPIs ? > > ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
