[kvm-devel] Extboot Option ROM rewritten in C - v2

2008-04-16 Thread Nguyen Anh Quynh
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

Re: [kvm-devel] Extboot Option ROM rewritten in C - v2

2008-04-16 Thread 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

Re: [kvm-devel] Extboot Option ROM rewritten in C - v2

2008-04-16 Thread 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

Re: [kvm-devel] Extboot Option ROM rewritten in C - v2

2008-04-16 Thread 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

Re: [kvm-devel] Extboot Option ROM rewritten in C - v2

2008-04-16 Thread Nguyen Anh Quynh
On Thu, Apr 17, 2008 at 12:02 AM, Anthony Liguori [EMAIL PROTECTED] 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