Menu
▾
▴
kvm-devel
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-17 01:30:20
Attachments:
extboot3.diff
|
This patch replaces the current assembly code of Extboot option rom with new C code. Patch is against kvm-66. This version returns an error code in case int 13 handler cannot handle a requested function. Signed-off-by: Nguyen Anh Quynh <aq...@gm...> # diffstat extboot3.diff b/extboot/Makefile | 67 ++-- b/extboot/boot.S | 119 ++++++++ b/extboot/farvar.h | 113 ++++++++ b/extboot/rom.c | 366 ++++++++++++++++++++++++++ b/extboot/signrom.c | 83 ++++-- b/extboot/util.h | 89 ++++++ extboot/extboot.S | 705 ---------------------------------------------------- 7 files changed, 786 insertions(+), 756 deletions(-) |
|
From: H. P. A. <hp...@zy...> - 2008-04-17 06:02:20
|
Nguyen Anh Quynh wrote: > This patch replaces the current assembly code of Extboot option rom > with new C code. Patch is against kvm-66. > > This version returns an error code in case int 13 handler cannot > handle a requested function. > > Signed-off-by: Nguyen Anh Quynh <aq...@gm...> > + /* -fomit-frame-pointer might clobber %ebp */ + pushl %ebp + call setup + popl %ebp No, it might not. %ebx, %ebp, %esi, and %edi are guaranteed preserved; %eax, %ecx and %edx are clobbered. It's also prudent to call cld before jumping to C code. -hpa |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-18 10:57:48
|
On Thu, Apr 17, 2008 at 2:58 PM, H. Peter Anvin <hp...@zy...> wrote: > Nguyen Anh Quynh wrote: > > > This patch replaces the current assembly code of Extboot option rom > > with new C code. Patch is against kvm-66. > > > > This version returns an error code in case int 13 handler cannot > > handle a requested function. > > > > Signed-off-by: Nguyen Anh Quynh <aq...@gm...> > > > > > > + /* -fomit-frame-pointer might clobber %ebp */ > + pushl %ebp > + call setup > + popl %ebp > > > No, it might not. %ebx, %ebp, %esi, and %edi are guaranteed preserved; > %eax, %ecx and %edx are clobbered. > > It's also prudent to call cld before jumping to C code. OK, I will fix these in the next version. Thanks, Q |
|
From: H. P. A. <hp...@zy...> - 2008-04-17 06:03:41
|
> + .globl linux_boot > +linux_boot: > + cli > + cld > + mov $0x9000, %ax > + mov %ax, %ds > + mov %ax, %es > + mov %ax, %fs > + mov %ax, %gs > + mov %ax, %ss > + mov $0x8ffe, %sp > + ljmp $0x9000 + 0x20, $0 The hard use of segment 9000 is really highly unfortunate for bzImage, since it restricts its heap more than necessary. I suggest following the patterns used by the (new) Qemu loader. -hpa |
|
From: Carlo M. A. B. <ca...@sa...> - 2008-04-17 07:18:33
|
On Thu, Apr 17, 2008 at 10:30:27AM +0900, Nguyen Anh Quynh wrote: +++ b/extboot/farvar.h @@ -0,0 +1,113 @@ +// Code to access multiple segments within gcc. +// +// Copyright (C) 2008 Kevin O'Connor <ke...@ko...> +// +// This file may be distributed under the terms of the GNU GPLv3 license. IANAL but wouldn't this make extboot GPLv3 only? how that will interact with the GPLv2 extboot qemu? Carlo |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-18 11:01:39
|
On Thu, Apr 17, 2008 at 4:36 PM, Carlo Marcelo Arenas Belon <ca...@sa...> wrote: > On Thu, Apr 17, 2008 at 10:30:27AM +0900, Nguyen Anh Quynh wrote: > > +++ b/extboot/farvar.h > @@ -0,0 +1,113 @@ > +// Code to access multiple segments within gcc. > +// > +// Copyright (C) 2008 Kevin O'Connor <ke...@ko...> > +// > +// This file may be distributed under the terms of the GNU GPLv3 license. > > IANAL but wouldn't this make extboot GPLv3 only? how that will interact > with the GPLv2 extboot qemu? I am not sure if that is fine, but it might be better to have the same license for every code. I will contact Kevin when the next version is ready (I am still fixing something) Thanks, Q |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-18 11:00:24
|
On Thu, Apr 17, 2008 at 3:00 PM, H. Peter Anvin <hp...@zy...> wrote: > > + .globl linux_boot > > +linux_boot: > > + cli > > + cld > > + mov $0x9000, %ax > > + mov %ax, %ds > > + mov %ax, %es > > + mov %ax, %fs > > + mov %ax, %gs > > + mov %ax, %ss > > + mov $0x8ffe, %sp > > + ljmp $0x9000 + 0x20, $0 > > > > The hard use of segment 9000 is really highly unfortunate for bzImage, > since it restricts its heap more than necessary. I suggest following the > patterns used by the (new) Qemu loader. Actually, this code is left from the original code of Anthony, and it seems he took it from qemu 0.8 version. Anthony, may you explain why you want to hijact the linux boot process here? If I understand correctly, we can just let the original int19 execute, and if linux boot is desired, it would work in normal way. So why you want to do this? Thanks, Q |
|
From: H. P. A. <hp...@zy...> - 2008-04-18 12:42:51
|
Nguyen Anh Quynh wrote: > > Actually, this code is left from the original code of Anthony, and it > seems he took it from qemu 0.8 version. > > Anthony, may you explain why you want to hijact the linux boot process > here? If I understand correctly, we can just let the original int19 > execute, and if linux boot is desired, it would work in normal way. So > why you want to do this? > I'm having exactly the *opposite* question... why does extboot have code to hook int 13h? -hpa |
|
From: H. P. A. <hp...@zy...> - 2008-04-18 12:46:09
|
Nguyen Anh Quynh wrote: > > Actually, this code is left from the original code of Anthony, and it > seems he took it from qemu 0.8 version. > > Anthony, may you explain why you want to hijact the linux boot process > here? If I understand correctly, we can just let the original int19 > execute, and if linux boot is desired, it would work in normal way. So > why you want to do this? > I'm having exactly the *opposite* question... why does extboot have code to hook int 13h? -hpa |
|
From: Anthony L. <ali...@us...> - 2008-04-18 13:20:03
|
H. Peter Anvin wrote: > Nguyen Anh Quynh wrote: >> >> Actually, this code is left from the original code of Anthony, and it >> seems he took it from qemu 0.8 version. >> >> Anthony, may you explain why you want to hijact the linux boot process >> here? If I understand correctly, we can just let the original int19 >> execute, and if linux boot is desired, it would work in normal way. So >> why you want to do this? >> > > I'm having exactly the *opposite* question... why does extboot have > code to hook int 13h? extboot is primarily intended to allow scsi boot or boot from a pv disk. It hooks int13h to fake out disk access. Regards, Anthony Liguori > -hpa |
|
From: Anthony L. <ali...@us...> - 2008-04-18 13:19:34
|
Nguyen Anh Quynh wrote: > On Thu, Apr 17, 2008 at 3:00 PM, H. Peter Anvin <hp...@zy...> wrote: > >>> + .globl linux_boot >>> +linux_boot: >>> + cli >>> + cld >>> + mov $0x9000, %ax >>> + mov %ax, %ds >>> + mov %ax, %es >>> + mov %ax, %fs >>> + mov %ax, %gs >>> + mov %ax, %ss >>> + mov $0x8ffe, %sp >>> + ljmp $0x9000 + 0x20, $0 >>> >>> >> The hard use of segment 9000 is really highly unfortunate for bzImage, >> since it restricts its heap more than necessary. I suggest following the >> patterns used by the (new) Qemu loader. >> > > Actually, this code is left from the original code of Anthony, and it > seems he took it from qemu 0.8 version. > > Anthony, may you explain why you want to hijact the linux boot process > here? If I understand correctly, we can just let the original int19 > execute, and if linux boot is desired, it would work in normal way. So > why you want to do this? > The thinking is to eliminate the need to hijack the boot sector when using the -kernel option. However, the linux boot stuff in extboot has been broken since hpa rewrote the boot code. It can be removed for now and I'll eventually revisit it. Regards, Anthony Liguori > Thanks, > Q > |
|
From: H. P. A. <hp...@zy...> - 2008-04-18 13:35:17
|
Anthony Liguori wrote: > > The thinking is to eliminate the need to hijack the boot sector when > using the -kernel option. However, the linux boot stuff in extboot has > been broken since hpa rewrote the boot code. It can be removed for now > and I'll eventually revisit it. > It probably makes more sense to have a different boot ROM for that. I thought this was extboot, but apparently not. I probably can throw something together. -hpa |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-18 13:56:08
|
On 4/18/08, Anthony Liguori <ali...@us...> wrote: > Nguyen Anh Quynh wrote: > > > On Thu, Apr 17, 2008 at 3:00 PM, H. Peter Anvin <hp...@zy...> wrote: > > > > > > > > > > > + .globl linux_boot > > > > +linux_boot: > > > > + cli > > > > + cld > > > > + mov $0x9000, %ax > > > > + mov %ax, %ds > > > > + mov %ax, %es > > > > + mov %ax, %fs > > > > + mov %ax, %gs > > > > + mov %ax, %ss > > > > + mov $0x8ffe, %sp > > > > + ljmp $0x9000 + 0x20, $0 > > > > > > > > > > > > > > > The hard use of segment 9000 is really highly unfortunate for bzImage, > > > since it restricts its heap more than necessary. I suggest following > the > > > patterns used by the (new) Qemu loader. > > > > > > > > > > Actually, this code is left from the original code of Anthony, and it > > seems he took it from qemu 0.8 version. > > > > Anthony, may you explain why you want to hijact the linux boot process > > here? If I understand correctly, we can just let the original int19 > > execute, and if linux boot is desired, it would work in normal way. So > > why you want to do this? > > > > > > The thinking is to eliminate the need to hijack the boot sector when using > the -kernel option. I see, but does that offer any advantage over the current approach? Thanks, Q |
|
From: Anthony L. <ali...@us...> - 2008-04-18 16:23:53
|
Nguyen Anh Quynh wrote: >> >> The thinking is to eliminate the need to hijack the boot sector when using >> the -kernel option. >> > > I see, but does that offer any advantage over the current approach? > You no longer have to specify a -hda option when using -kernel. Regards, Anthony Liguori > Thanks, > Q > |
|
From: H. P. A. <hp...@zy...> - 2008-04-18 14:54:11
|
Anthony Liguori wrote: > Nguyen Anh Quynh wrote: >>> >>> The thinking is to eliminate the need to hijack the boot sector when >>> using >>> the -kernel option. >>> >> >> I see, but does that offer any advantage over the current approach? >> > > You no longer have to specify a -hda option when using -kernel. > Plus, you don't have funny side effects if you do -- and I suspect there is ad hoc code in the disk driver which can be removed. -hpa |
|
From: Nguyen A. Q. <aq...@gm...> - 2008-04-18 15:02:55
|
On 4/18/08, Anthony Liguori <ali...@us...> wrote: > Nguyen Anh Quynh wrote: > > > > > > > > > The thinking is to eliminate the need to hijack the boot sector when > using > > > the -kernel option. > > > > > > > > > > I see, but does that offer any advantage over the current approach? > > > > > > You no longer have to specify a -hda option when using -kernel. Without -hda, how can we load disk image? Or you mean you only want to test the kernel? Thanks, Q |
|
From: Anthony L. <ali...@us...> - 2008-04-18 15:20:29
|
Nguyen Anh Quynh wrote: >> You no longer have to specify a -hda option when using -kernel. >> > > Without -hda, how can we load disk image? Or you mean you only want to > test the kernel? > Right. You may be booting from NFS, iSCSI, or something like that. Regards, Anthony Liguori > Thanks, > Q > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X