WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] [Firmware] TCG BIOS extensions for the Bochs BIO

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [Firmware] TCG BIOS extensions for the Bochs BIOS
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Tue, 12 Dec 2006 10:25:23 -0500
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Delivery-date: Tue, 12 Dec 2006 07:25:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1A32D1F.5DB1%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

Keir Fraser <keir@xxxxxxxxxxxxx> wrote on 12/11/2006 10:43:27 AM:

>
> I would imagine this working by having generic real-mode/32-bit
> gateway routines in rombios, and then getting the hell out to 32-bit
> protected mode asap for new code. The advantages are that you get to
> code in C, compiled with a modern optimising compiler (gcc), and
> that you avoid the silly 64kB limitation. As you say, hvmloader


Since I am running out of space in the BIOS segment now while converting the functions to 'C'...
Do you know of some good 'constructs' that can be left in the rombios as markers for linking the two pieces? I'd like to start with lifting up a single function into 32 bit space and then continuously put more up there, but get the linking right. Probably funneling everything through a single function and demultiplexing in 32 bit space is not what we would want.

I suppose HVMloader will have to carry a relocateable file (-fPIC) and be able to re-locate it to whatever memory could be reserved.

   Stefan

> would be responsible for poking the routines into high memory,
> marking them as E820_RESERVED, and then doing some jump-table poking
> in rombios (which might more generically, and grandiosely, be termed
> ‘linking’ of the BIOS and its extensions :-).
>
> TBH I’m not happy to check in big gobs of assembly code, or even
> really bcc C/asm code. We should do the leg work to be able to use
> gcc. An hvmloader type of environment is what we should aim for --  
> another way of looking at this is removing hvmloader’s restriction
> of only running at bootstrap so that it can also provide ongoing
> run-time services.
>
>  -- Keir
>
> On 11/12/06 15:26, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

> Someone who wants to add new functionality to the Bochs BIOS might
> care about the amount of free space in that 64kb segment. Currently
> there's enough room left even with the TPM extensions.
> Even if we move these extensions to some 32bit area, the hook into
> the 1Ah interrupt and all those other function calls surrounded by
> #if BX_TCGBIOS in rombios.c are needed as well as later on some code
> that switches into protected mode and jumps up into the 32 bit area.
> The BIOS code should at some point be compiled with those TPM
> extensions independent of whether a TPM is available in the VM or
> not. The extensions don't influence the BIOS if a TPM is not available.
>
> How would you connect the two code areas and the functions? Would
> hvmloader write the 32 bit address somewhere into the Bochs BIOS and
> the to reach the 32 bit area one uses a jump table to call all those
> functions up there? I'd really rather leave the TPM extensions in
> the BIOS segment for now. The bulk of the code is located in its own
> file anyway. I will convert parts of the code to 'C', though.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel