Hi Stefan,
I'm CC'ing the mailing list.
On Wed, Nov 24, 2010 at 11:45:17AM -0500, Stefan Berger wrote:
Hi Kevin,
while I am porting the BIOS code for TCG support to SeaBIOS, I am wondering about the following:
'When' is it recommendable to switch from 16 bit to 32bit.
To be honest, this has never really been done before in SeaBIOS, so I think we'll have to figure this out as we go. Since you need to access full memory, it looks like it will be required to jump into 32bit mode.
I am asking because the interface I am implementing allows callers to pass input and output data structures using es:di and ds:si, with es and ds allowed to be loaded with anything possible. So my strategy in the Bochs BIOS was to switch to 32 bit even before calling the interrupt handler, there doing the case statement for branching into the actual functions (switch (regs->al)) and passing 32 bit pointers converted from es:di and ds:si to the functions doing the work and reading from those memory locations.
This sounds okay to me - it should be possible to implement handle_1abb(regs) which does a call32(tcg32_1abb, regs). It's possible to do all the pointer conversion while in 32bit mode.
The 'thing' is also that several ones of the functions that can be called through the interrupt interface are also called from the implemented functions. Example:
Functions A,B,C can be called via the interrupt handler.
Function B also calls A. Function C also calls B.
This shouldn't really be an issue. The build should take care of this.
This is due to the hierarchical nature of the functions. Also, while for example B calls A, B fills a data structure (on the stack) that it passes to A. A of course can get the same data structure from the user calling the interrupt interface. So, by switching to 32 bit mode and converting to 32 bit pointers early I could previously avoid a lot of headaches with the segment registers in 16 bit mode and reading the data from wherever they may be. Would you have any concerns about switching to 32 bit mode early, so that the interrupt handler and anything subsequent runs in 32 bit mode?
I can't say for sure what will make sense without seeing the code first, but it sounds okay to me.
-Kevin
Regards, Stefan
On 11/25/2010 08:35 AM, Kevin O'Connor wrote:
This is due to the hierarchical nature of the functions. Also, while for example B calls A, B fills a data structure (on the stack) that it passes to A. A of course can get the same data structure from the user calling the interrupt interface. So, by switching to 32 bit mode and converting to 32 bit pointers early I could previously avoid a lot of headaches with the segment registers in 16 bit mode and reading the data from wherever they may be. Would you have any concerns about switching to 32 bit mode early, so that the interrupt handler and anything subsequent runs in 32 bit mode?
I can't say for sure what will make sense without seeing the code first, but it sounds okay to me.
I posted the TPM patches yesterday on the Qemu mailing list. It may take some time until TPM functionality becomes available in Qemu, but would you be willing to review the BIOS extensions even without being able to run them (for some time)? It's quite a chunk...
Stefan
On Fri, Feb 25, 2011 at 10:35:04AM -0500, Stefan Berger wrote:
On 11/25/2010 08:35 AM, Kevin O'Connor wrote:
This is due to the hierarchical nature of the functions. Also, while for example B calls A, B fills a data structure (on the stack) that it passes to A. A of course can get the same data structure from the user calling the interrupt interface. So, by switching to 32 bit mode and converting to 32 bit pointers early I could previously avoid a lot of headaches with the segment registers in 16 bit mode and reading the data from wherever they may be. Would you have any concerns about switching to 32 bit mode early, so that the interrupt handler and anything subsequent runs in 32 bit mode?
I can't say for sure what will make sense without seeing the code first, but it sounds okay to me.
I posted the TPM patches yesterday on the Qemu mailing list. It may take some time until TPM functionality becomes available in Qemu, but would you be willing to review the BIOS extensions even without being able to run them (for some time)? It's quite a chunk...
Hi Stefan,
Yes - please break the patch up into chunks and send it to the list.
Thanks, -Kevin
On 02/28/2011 09:55 PM, Kevin O'Connor wrote:
On Fri, Feb 25, 2011 at 10:35:04AM -0500, Stefan Berger wrote:
On 11/25/2010 08:35 AM, Kevin O'Connor wrote:
This is due to the hierarchical nature of the functions. Also, while for example B calls A, B fills a data structure (on the stack) that it passes to A. A of course can get the same data structure from the user calling the interrupt interface. So, by switching to 32 bit mode and converting to 32 bit pointers early I could previously avoid a lot of headaches with the segment registers in 16 bit mode and reading the data from wherever they may be. Would you have any concerns about switching to 32 bit mode early, so that the interrupt handler and anything subsequent runs in 32 bit mode?
I can't say for sure what will make sense without seeing the code first, but it sounds okay to me.
I posted the TPM patches yesterday on the Qemu mailing list. It may take some time until TPM functionality becomes available in Qemu, but would you be willing to review the BIOS extensions even without being able to run them (for some time)? It's quite a chunk...
Hi Stefan,
Yes - please break the patch up into chunks and send it to the list.
I mailed them today to seabios@seabios.org but didn't see them coming back or showing up on the webpage. I cc'ed the Qemu mailing list and there they are.
Stefan
Thanks, -Kevin
On Wed, Mar 30, 2011 at 07:31:23PM -0400, Stefan Berger wrote:
I mailed them today to seabios@seabios.org but didn't see them coming back or showing up on the webpage. I cc'ed the Qemu mailing list and there they are.
Stefan
The mailing list had a blip yesterday - but it should be okay now.
-Kevin
-
Kevin O'Connor -
Stefan Berger