>>> On 23.12.11 at 04:14, "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]> > Acked-by: Keir Fraser <[email protected]> > Acked-by: Tim Deegan <[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 Fri Dec 23 11:01:10 2011 +0800 > @@ -42,6 +42,7 @@ > #include <asm/msr.h> > #include <asm/mtrr.h> > #include <asm/time.h> > +#include <asm/tboot.h> > #include <mach_apic.h> > #include <mach_wakecpu.h> > #include <smpboot_hooks.h> > @@ -463,6 +464,18 @@ > send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY; > } while ( send_status && (timeout++ < 1000) ); > } > + else if ( tboot_in_measured_env() ) > + { > + /* > + * With tboot AP is actually spinning in a mini-guest before > + * receiving INIT. Upon receiving INIT ipi, AP need time to VMExit, > > + * update VMCS to tracking SIPIs and VMResume. > + * > + * While AP is in root mode handling the INIT the CPU will drop > + * any SIPIs > + */ > + udelay(10);
So you jumped from 100ms to 10us - how was that value established? Or in other words, how certain is it that this (or any other) timeout is sufficient for all current and future systems implementing tboot? 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
