This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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/
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

 -- Keir

Xen-devel mailing list