| |
|
 |
|
 |
|
|
|
| |
|
|
xense-devel
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology
|
To: |
"Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>, <xense-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview |
|
From: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
|
Date: |
Sat, 09 Jun 2007 11:00:56 +0100 |
|
Cc: |
"Wang, Shane" <shane.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> |
|
Delivery-date: |
Sat, 09 Jun 2007 02:56:32 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<D936D925018D154694D8A362EEB08920019E08E1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
AceqLrHw9k0eE1VGTGivJ8LlKk1LqAATmB7N |
|
Thread-topic: |
[Xen-devel] [RFC][PATCH][0/2] Intel(r) Trusted Execution Technology support: Overview |
|
User-agent: |
Microsoft-Entourage/11.3.3.061214 |
On 9/6/07 01:39, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
> o sboot is always built 32bit and runs in protected mode without PAE or
> paging enabled. sboot lives at (copies itself to) 0x70000. This seems
> like a safe location so far, but is not a good long-term location. We'd
> like to discuss moving Xen a little higher to allow sboot to live at
> 0x100000--this is a separate thread.
What's wrong with 0x70000?
> o The code requires that VT be enabled as well as TXT. This is because
> the mechanism for bringing up the APs uses VMX to create a mini-VM in
> order to trap on INIT-SIPI-SIPI.
It looks like you do your best to avoid real mode. Unfortunately the BP now
returns to real mode to do various system initialisation work. Do you need a
VMX container for any reason other than to trap INIT-SIPI-SIPI? Possibly we
could agree on a higher-level method for cpu online/offline.
The Xen changes are largely pretty reasonable I think. It would be nice to
know that they are sufficient for the AMD secure boot module also, since we
obviously don't want two sets of changes for the same overall purpose.
It'd be nice to have some way of detecting sboot other than through e820
(which can sometimes be a bit random). If you keep the VMX container then
maybe CPUID(0x40000000)?
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home