|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologys
To: |
Jan Beulich <jbeulich@xxxxxxxxxx>, Joseph Cihula <joseph.cihula@xxxxxxxxx> |
Subject: |
Re: [Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview |
From: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
Date: |
Wed, 29 Aug 2007 17:56:18 +0100 |
Cc: |
xen-devel@xxxxxxxxxxxxxxxxxxx, Edwin Zhai <edwin.zhai@xxxxxxxxx>, James Xu <james.xu@xxxxxxxxx>, Shane Wang <shane.wang@xxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx, Gang Wei <gang.wei@xxxxxxxxx> |
Delivery-date: |
Wed, 29 Aug 2007 09:57:13 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C2FB053C.14FBB%keir@xxxxxxxxxxxxx> |
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: |
AcfqJS1qa85J3FYYEdyVXAAX8io7RQAOFci6 |
Thread-topic: |
[Xen-devel] [RFC][PATCH][0/4] Intel(R) Trusted Execution Technologysupport: Overview |
User-agent: |
Microsoft-Entourage/11.3.6.070618 |
On 29/8/07 11:13, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
> Indeed, and this also needs solving for kexec of Xen, too: it is unsafe to
> drop back into real mode with interrupts enabled when chain booted. This
> problem is sidestepped for Linux because kexec simply strips off Linux's
> real-mode loader and sets up the boot-sector information as if the real-mode
> section had run. But actually no real-mode execution happens.
Actually I see that kexec doesn't really pass much real information to the
loaded kernel. It fakes out video info and EDID/EDD stuff is not to be seen.
But I don't think it changes the fact that the easiest way to solve this
particular problem in full is to extend the multiboot information format.
Sboot can then take full advantage of the extension, and the e820 hack goes
away, while kexec can at least use it to avoid needing manual specification
of no-real-mode, and can pass at least what useful information it is able to
gather.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|