Extboot Option ROM rewritten in C - v2

Extboot Option ROM rewritten in C - v2

[Nguyen Anh Quynh]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

Hi Anthony,

I found a bug in the last code: send_command() failed to copy back the
result into extboot_cmd structure. This patch fixes it.

I succesfully tested this version with guest Win2K (fully updated,
scsi boot) and Linux 2.6.25-rc8 (virtio).

Let me know if you can boot Windows with this version.

Thanks,
Quynh
---
This code is an attempt to rewrite the current extboot option rom in
C. The new code now minimize the assembly code, so that the assembly
code is very small and simple: boot.S's only job is to interface with
C code, which does all the dirty job. "signrom" is modified to adapt
with the new result binary image.

The result option rom has the same size as the original one: 1.5KB,
while the actual code size is around the same: 1.2KB (gcc can optimize
really well)

To install this option rom, do the following steps as root:

make
make save         <--- backup the original option rom to
/usr/share/qemu/extboot.bin.org
make install       <--- overwrite the new option rom to
/usr/share/qemu/extboot.bin

[-- Attachment #2: extboot2.tbz2 --]
[-- Type: application/octet-stream, Size: 6956 bytes --]

[-- Attachment #3: Type: text/plain, Size: 320 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

[-- Attachment #4: Type: text/plain, Size: 158 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Extboot Option ROM rewritten in C - v2

[Anthony Liguori]

Nguyen Anh Quynh wrote:
> Hi Anthony,
>
> I found a bug in the last code: send_command() failed to copy back the
> result into extboot_cmd structure. This patch fixes it.
>
> I succesfully tested this version with guest Win2K (fully updated,
> scsi boot) and Linux 2.6.25-rc8 (virtio).
>
> Let me know if you can boot Windows with this version.
>   

I'll test it out.  Please send it to the list as a patch against 
kvm-userspace.

Regards,

Anthony Liguori

> Thanks,
> Quynh
> ---
> This code is an attempt to rewrite the current extboot option rom in
> C. The new code now minimize the assembly code, so that the assembly
> code is very small and simple: boot.S's only job is to interface with
> C code, which does all the dirty job. "signrom" is modified to adapt
> with the new result binary image.
>
> The result option rom has the same size as the original one: 1.5KB,
> while the actual code size is around the same: 1.2KB (gcc can optimize
> really well)
>
> To install this option rom, do the following steps as root:
>
> make
> make save         <--- backup the original option rom to
> /usr/share/qemu/extboot.bin.org
> make install       <--- overwrite the new option rom to
> /usr/share/qemu/extboot.bin
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: Extboot Option ROM rewritten in C - v2

[Anthony Liguori]

A couple general comments.

I'd feel a lot more comfortable with the int13 handler returning an int 
and the asm stub code uses that result to determine how to set CF.  You 
set CF deep within the function stack and there's no guarantee that GCC 
isn't going to stomp on it.

I also don't think we want to raise int18 when we get a command we don't 
understand.  We should just not change any of the register state.  There 
are a number of extended commands that look for a magic value to 
determine whether the command exists or not.

Regards,

Anthony Liguori

Nguyen Anh Quynh wrote:
> Hi Anthony,
>
> I found a bug in the last code: send_command() failed to copy back the
> result into extboot_cmd structure. This patch fixes it.
>
> I succesfully tested this version with guest Win2K (fully updated,
> scsi boot) and Linux 2.6.25-rc8 (virtio).
>
> Let me know if you can boot Windows with this version.
>
> Thanks,
> Quynh
> ---
> This code is an attempt to rewrite the current extboot option rom in
> C. The new code now minimize the assembly code, so that the assembly
> code is very small and simple: boot.S's only job is to interface with
> C code, which does all the dirty job. "signrom" is modified to adapt
> with the new result binary image.
>
> The result option rom has the same size as the original one: 1.5KB,
> while the actual code size is around the same: 1.2KB (gcc can optimize
> really well)
>
> To install this option rom, do the following steps as root:
>
> make
> make save         <--- backup the original option rom to
> /usr/share/qemu/extboot.bin.org
> make install       <--- overwrite the new option rom to
> /usr/share/qemu/extboot.bin
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: Extboot Option ROM rewritten in C - v2

[Anthony Liguori]

Anthony Liguori wrote:
> A couple general comments.
>
> I'd feel a lot more comfortable with the int13 handler returning an 
> int and the asm stub code uses that result to determine how to set 
> CF.  You set CF deep within the function stack and there's no 
> guarantee that GCC isn't going to stomp on it.

Ignore that bit, I missed that you were only setting it within the regs 
structure.

Regards,

Anthony Liguori

> I also don't think we want to raise int18 when we get a command we 
> don't understand.  We should just not change any of the register 
> state.  There are a number of extended commands that look for a magic 
> value to determine whether the command exists or not.
>
> Regards,
>
> Anthony Liguori
>
> Nguyen Anh Quynh wrote:
>> Hi Anthony,
>>
>> I found a bug in the last code: send_command() failed to copy back the
>> result into extboot_cmd structure. This patch fixes it.
>>
>> I succesfully tested this version with guest Win2K (fully updated,
>> scsi boot) and Linux 2.6.25-rc8 (virtio).
>>
>> Let me know if you can boot Windows with this version.
>>
>> Thanks,
>> Quynh
>> ---
>> This code is an attempt to rewrite the current extboot option rom in
>> C. The new code now minimize the assembly code, so that the assembly
>> code is very small and simple: boot.S's only job is to interface with
>> C code, which does all the dirty job. "signrom" is modified to adapt
>> with the new result binary image.
>>
>> The result option rom has the same size as the original one: 1.5KB,
>> while the actual code size is around the same: 1.2KB (gcc can optimize
>> really well)
>>
>> To install this option rom, do the following steps as root:
>>
>> make
>> make save         <--- backup the original option rom to
>> /usr/share/qemu/extboot.bin.org
>> make install       <--- overwrite the new option rom to
>> /usr/share/qemu/extboot.bin
>>   
>
>


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: Extboot Option ROM rewritten in C - v2

[Nguyen Anh Quynh]

On Thu, Apr 17, 2008 at 12:02 AM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> A couple general comments.
>
>  I'd feel a lot more comfortable with the int13 handler returning an int and
> the asm stub code uses that result to determine how to set CF.  You set CF
> deep within the function stack and there's no guarantee that GCC isn't going
> to stomp on it.
>
>  I also don't think we want to raise int18 when we get a command we don't
> understand.  We should just not change any of the register state.  There are
> a number of extended commands that look for a magic value to determine
> whether the command exists or not.

Absolutely. We should return error code in that case.

Thanks,
Quynh

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone