I think that the control flow of CPU is as follows: grub -> tboot -> xen -> guest OS. If we only consider the process of loading guest OS, regardless of handling the sleep states and shutdown event, the guest OS should be launched successfully. In other words, if xen does not support tboot, the guest OS should also be launched successfully, but I've failed in such a way. 
   Is it because that the assumption of control flow is wrong? if it is, then what is the right cotrol flow?

Best regards,

On Sun, May 19, 2013 at 3:36 PM, henry del <idelhenry@gmail.com> wrote:

On Sun, May 19, 2013 at 10:15 AM, Wei, Gang <gang.wei@intel.com> wrote:
henry del wrote on 2013-05-18:
>>         Thank you for your prompt reply. Yet I have another question.
>> According to the TXT spec, if GETSEC[SENTER] leaf function has not been
>> used to launch a measured environment, it's impossible to make use of
>> locality 1-4. Because registers in the private space can only be
>> accessed after a measured environment has been established, while these
>> registers control whether to unlock the locality 1-4.  That means that
>> if bitvisor wants to use PCR, locality of which is above 0, bitvisor
>> need to support txt. Is that correct?

>Correct. PCR17~22 can't be extended in locality 0.

>>         So if I port xen/arch/x86/tboot.c and relevant files into bitvisor
>> and modify the grub.lst, this way will work for bitvisor?

I have compared the tboot implementation in kernel 3.2.2 to that of xen, they are much different. The important files: tboot.c and tboot.h are supported differently in xen and kernel.
   I think that both xen and kernel have full control of hardware sources when booted separatedly by tboot. Why do xen and linux kernel have a different implementation of tboot? Or is it enough for me only to refer to tboot support in xen when I work for bitvisor?