[Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Anthony Liguori]

Hi,

I just wanted to let everyone know that I've switched the PC machine 
type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC, 
by Kevin O'Conner, along with quite a lot of clean up and new feature work.

gPXE is the new development tree of etherboot which is now deprecated.  
We've done a lot of testing of and while there are a few outstanding 
issues, almost everything seems to be working okay.

Some known issues:
 o e1000 pxe booting doesn't seem to work
 o gPXE does not like the slirp tftp server
 o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)

I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in 
SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an 
effort to debug.

I want to thank everyone who helped make this all happen.  It was a big 
effort and I think it's going to be a really nice feature for the 0.12.0 
release!

-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Jan Kiszka]

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

Anthony Liguori wrote:
> Hi,
> 
> I just wanted to let everyone know that I've switched the PC machine
> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
> by Kevin O'Conner, along with quite a lot of clean up and new feature work.
> 
> gPXE is the new development tree of etherboot which is now deprecated. 
> We've done a lot of testing of and while there are a few outstanding
> issues, almost everything seems to be working okay.
> 
> Some known issues:
> o e1000 pxe booting doesn't seem to work
> o gPXE does not like the slirp tftp server

Can't confirm, works nicely here with default settings (e1000).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Anthony Liguori]

Jan Kiszka wrote:
> Anthony Liguori wrote:
>   
>> Hi,
>>
>> I just wanted to let everyone know that I've switched the PC machine
>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>> by Kevin O'Conner, along with quite a lot of clean up and new feature work.
>>
>> gPXE is the new development tree of etherboot which is now deprecated. 
>> We've done a lot of testing of and while there are a few outstanding
>> issues, almost everything seems to be working okay.
>>
>> Some known issues:
>> o e1000 pxe booting doesn't seem to work
>> o gPXE does not like the slirp tftp server
>>     
>
> Can't confirm, works nicely here with default settings (e1000).
>   

Interesting.  I'll have to look again.

> Jan
>   


-- 
Regards,

Anthony Liguori

[Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Stefan Weil]

Anthony Liguori schrieb:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>> Hi,
>>>
>>> I just wanted to let everyone know that I've switched the PC machine
>>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>>> by Kevin O'Conner, along with quite a lot of clean up and new
>>> feature work.
>>>
>>> gPXE is the new development tree of etherboot which is now
>>> deprecated. We've done a lot of testing of and while there are a few
>>> outstanding
>>> issues, almost everything seems to be working okay.
>>>
>>> Some known issues:
>>> o e1000 pxe booting doesn't seem to work
>>> o gPXE does not like the slirp tftp server
>>>     
>>
>> Can't confirm, works nicely here with default settings (e1000).
>>   
>
> Interesting.  I'll have to look again.

Hi,

it loads the ROM, but ROM and e1000 don't match.
I tested with a fresh build.

Jan, did you check that qemu uses the correct bios path?
Maybe -L <dir> was missing.

Regards,
Stefan

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Jan Kiszka]

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

Stefan Weil wrote:
> Anthony Liguori schrieb:
>> Jan Kiszka wrote:
>>> Anthony Liguori wrote:
>>>  
>>>> Hi,
>>>>
>>>> I just wanted to let everyone know that I've switched the PC machine
>>>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>>>> by Kevin O'Conner, along with quite a lot of clean up and new
>>>> feature work.
>>>>
>>>> gPXE is the new development tree of etherboot which is now
>>>> deprecated. We've done a lot of testing of and while there are a few
>>>> outstanding
>>>> issues, almost everything seems to be working okay.
>>>>
>>>> Some known issues:
>>>> o e1000 pxe booting doesn't seem to work
>>>> o gPXE does not like the slirp tftp server
>>>>     
>>> Can't confirm, works nicely here with default settings (e1000).
>>>   
>> Interesting.  I'll have to look again.
> 
> Hi,
> 
> it loads the ROM, but ROM and e1000 don't match.

But they work together if you do not specify '-boot n' and go via the
command prompt instead.

> I tested with a fresh build.
> 
> Jan, did you check that qemu uses the correct bios path?
> Maybe -L <dir> was missing.

Yes, it's correct and -L makes no difference.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Beth Kon]

Jan Kiszka wrote:
> Stefan Weil wrote:
>   
>> Anthony Liguori schrieb:
>>     
>>> Jan Kiszka wrote:
>>>       
>>>> Anthony Liguori wrote:
>>>>  
>>>>         
>>>>> Hi,
>>>>>
>>>>> I just wanted to let everyone know that I've switched the PC machine
>>>>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>>>>> by Kevin O'Conner, along with quite a lot of clean up and new
>>>>> feature work.
>>>>>
>>>>> gPXE is the new development tree of etherboot which is now
>>>>> deprecated. We've done a lot of testing of and while there are a few
>>>>> outstanding
>>>>> issues, almost everything seems to be working okay.
>>>>>
>>>>> Some known issues:
>>>>> o e1000 pxe booting doesn't seem to work
>>>>> o gPXE does not like the slirp tftp server
>>>>>     
>>>>>           
>>>> Can't confirm, works nicely here with default settings (e1000).
>>>>   
>>>>         
>>> Interesting.  I'll have to look again.
>>>       
>> Hi,
>>
>> it loads the ROM, but ROM and e1000 don't match.
>>     
>
> But they work together if you do not specify '-boot n' and go via the
> command prompt instead.
>
>   
>> I tested with a fresh build.
>>
>> Jan, did you check that qemu uses the correct bios path?
>> Maybe -L <dir> was missing.
>>     
>
> Yes, it's correct and -L makes no difference.
>
> Jan
>
>   
Serendipity allowed us to find this really easily, thanks to some old 
builds lying around...

The following Seabios commit breaks gpxe boot with e1000:

commit a5826b5ad482f44d293387dc7513e5e98802a54e
Author: Kevin O'Connor <kevin@koconnor.net>
Date:   Sat Oct 24 17:57:29 2009 -0400

    Add simple cooperative threading scheme to allow parallel hw init.
   
    Enable system for running hardware initialization in parallel.
    The yield() call can now round-robin between "threads".
    Rework ata controller init to use a thread per controller.
    Make sure internal drives are registered in a defined order.
    Run keyboard initialization in a thread.
    Rework usb init to use a thread per controller.

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Anthony Liguori]

Beth Kon wrote:
> Serendipity allowed us to find this really easily, thanks to some old 
> builds lying around...
>
> The following Seabios commit breaks gpxe boot with e1000:
>
> commit a5826b5ad482f44d293387dc7513e5e98802a54e
> Author: Kevin O'Connor <kevin@koconnor.net>
> Date:   Sat Oct 24 17:57:29 2009 -0400
>
>    Add simple cooperative threading scheme to allow parallel hw init.
>      Enable system for running hardware initialization in parallel.
>    The yield() call can now round-robin between "threads".
>    Rework ata controller init to use a thread per controller.
>    Make sure internal drives are registered in a defined order.
>    Run keyboard initialization in a thread.
>    Rework usb init to use a thread per controller.

Any thoughts Kevin?

Before this commit, the gPXE e1000 rom was able to successfully netboot 
when selected as a boot device.  With this commit, we get a "device not 
found" error within gPXE when launched as a boot device but when run 
from the gPXE command line, it launches successfully.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Kevin O'Connor]

On Mon, Nov 02, 2009 at 05:22:00PM -0600, Anthony Liguori wrote:
> Beth Kon wrote:
>> Serendipity allowed us to find this really easily, thanks to some old  
>> builds lying around...
>>
>> The following Seabios commit breaks gpxe boot with e1000:
[...]
> Any thoughts Kevin?
>
> Before this commit, the gPXE e1000 rom was able to successfully netboot  
> when selected as a boot device.  With this commit, we get a "device not  
> found" error within gPXE when launched as a boot device but when run  
> from the gPXE command line, it launches successfully.

The easist way to debug this is to enable debugging output.  It's
possible to modify qemu's hw/pc.c and enable DEBUG_BIOS, but it's
probably simpler to recompile SeaBIOS and set CONFIG_DEBUG_SERIAL in
src/config.h (and possibly increase CONFIG_DEBUG_LEVEL).

With the later, one can then run:

qemu -net nic,model=e1000 -boot n -serial stdio

and what comes out is:

Scan for option roms
Running option rom at c900:0003
pnp call arg1=60
pmm call arg1=0
Found option rom with bad checksum: loc=0x000c9000 len=72192 sum=37

So, the e1000 option rom is modifying itself and not properly updating
its checksum - thefore SeaBIOS doesn't consider it in its BEV list.
The fact that it changed in the commit highlighted above was probably
just random.

When was this gpxe rom built?  I know gpxe used to have an issue with
the checksum not being updated, but I thought that was fixed about six
months ago.

-Kevin

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Beth Kon]

Kevin O'Connor wrote:
> On Mon, Nov 02, 2009 at 05:22:00PM -0600, Anthony Liguori wrote:
>   
>> Beth Kon wrote:
>>     
>>> Serendipity allowed us to find this really easily, thanks to some old  
>>> builds lying around...
>>>
>>> The following Seabios commit breaks gpxe boot with e1000:
>>>       
> [...]
>   
>> Any thoughts Kevin?
>>
>> Before this commit, the gPXE e1000 rom was able to successfully netboot  
>> when selected as a boot device.  With this commit, we get a "device not  
>> found" error within gPXE when launched as a boot device but when run  
>> from the gPXE command line, it launches successfully.
>>     
>
> The easist way to debug this is to enable debugging output.  It's
> possible to modify qemu's hw/pc.c and enable DEBUG_BIOS, but it's
> probably simpler to recompile SeaBIOS and set CONFIG_DEBUG_SERIAL in
> src/config.h (and possibly increase CONFIG_DEBUG_LEVEL).
>
> With the later, one can then run:
>
> qemu -net nic,model=e1000 -boot n -serial stdio
>
> and what comes out is:
>
> Scan for option roms
> Running option rom at c900:0003
> pnp call arg1=60
> pmm call arg1=0
> Found option rom with bad checksum: loc=0x000c9000 len=72192 sum=37
>
> So, the e1000 option rom is modifying itself and not properly updating
> its checksum - thefore SeaBIOS doesn't consider it in its BEV list.
> The fact that it changed in the commit highlighted above was probably
> just random.
>
> When was this gpxe rom built?  I know gpxe used to have an issue with
> the checksum not being updated, but I thought that was fixed about six
> months ago.
>   
The rom was built about 2 weeks ago. But I don't follow what you're 
saying. The same rom works when the Seabios tree is reset to the commit 
just prior to this one. That would suggest to me that the rom isn't the 
problem. But I agree that there is no obvious connection between that 
commit and a bad checksum. What am I missing?
> -Kevin
>   

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Kevin O'Connor]

On Tue, Nov 03, 2009 at 09:11:40AM -0500, Beth Kon wrote:
> Kevin O'Connor wrote:
>> When was this gpxe rom built?  I know gpxe used to have an issue with
>> the checksum not being updated, but I thought that was fixed about six
>> months ago.
>>   
> The rom was built about 2 weeks ago. But I don't follow what you're  
> saying. The same rom works when the Seabios tree is reset to the commit  
> just prior to this one. That would suggest to me that the rom isn't the  
> problem. But I agree that there is no obvious connection between that  
> commit and a bad checksum. What am I missing?

I traced this down, and it looks like there is a series of subtle bugs
that led to this situation.

The bug causing the boot to fail is that gPXE didn't update its
checksum.  This was supposed to be fixed in gPXE commit f16668d, but
it looks like gPXE either regressed or the e1000 driver is special in
some way.

The reason SeaBIOS commit a5826b5a exposes this issue, is that commit
a5826b5a broke SeaBIOS' PMM support - the gPXE bug only shows up when
PMM is not available.

So, why did commit a5826b5a break PMM?  This appears to be some weird
interaction with gcc and its "-fwhole-program -combine" options.  One
of the variables (ZoneTmpHigh) is incorrectly marked by gcc as being
local instead of global after commit a5826b5a.  Unfortunately, instead
of getting an error, the build proceeded and had a bogus reference to
the ZoneTmpHigh variable - which caused PMM allocations to fail even
when there was memory.

I've reorganized the build slightly to work around this problem with
"-combine".  I've also updated the SeaBIOS linker scripts so that they
will cause a build failure if a similar issue arises in the future.
The latest SeaBIOS git should have this all working again (even with
the current e1000 gPXE).

It looks like SeaBIOS may have to stop using gcc's "-combine" option,
as this seems to be a bit fragile in various gcc builds.

-Kevin

Re: [Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Anthony Liguori]

Kevin O'Connor wrote:
> I traced this down, and it looks like there is a series of subtle bugs
> that led to this situation.
>
> The bug causing the boot to fail is that gPXE didn't update its
> checksum.  This was supposed to be fixed in gPXE commit f16668d, but
> it looks like gPXE either regressed or the e1000 driver is special in
> some way.
>
> The reason SeaBIOS commit a5826b5a exposes this issue, is that commit
> a5826b5a broke SeaBIOS' PMM support - the gPXE bug only shows up when
> PMM is not available.
>
> So, why did commit a5826b5a break PMM?  This appears to be some weird
> interaction with gcc and its "-fwhole-program -combine" options.  One
> of the variables (ZoneTmpHigh) is incorrectly marked by gcc as being
> local instead of global after commit a5826b5a.  Unfortunately, instead
> of getting an error, the build proceeded and had a bogus reference to
> the ZoneTmpHigh variable - which caused PMM allocations to fail even
> when there was memory.
>
> I've reorganized the build slightly to work around this problem with
> "-combine".  I've also updated the SeaBIOS linker scripts so that they
> will cause a build failure if a similar issue arises in the future.
> The latest SeaBIOS git should have this all working again (even with
> the current e1000 gPXE).
>   

Thanks for tracking this down Kevin!

Regards,

Anthony Liguori

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Stefan Weil]

Anthony Liguori schrieb:
> Hi,
>
> I just wanted to let everyone know that I've switched the PC machine
> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
> by Kevin O'Conner, along with quite a lot of clean up and new feature
> work.
>
> gPXE is the new development tree of etherboot which is now
> deprecated.  We've done a lot of testing of and while there are a few
> outstanding issues, almost everything seems to be working okay.
>
> Some known issues:
> o e1000 pxe booting doesn't seem to work
> o gPXE does not like the slirp tftp server
> o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
>
> I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
> SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
> effort to debug.
>
> I want to thank everyone who helped make this all happen.  It was a
> big effort and I think it's going to be a really nice feature for the
> 0.12.0 release!
>

More issues:

* QEMU crash with all working pxe devices:

i386-softmmu/qemu -boot n -net nic,model=pcnet -net user -L pc-bios
qemu: fatal: Trying to execute code outside RAM or ROM at 0x7e6005a8

EAX=00007b52 EBX=9c730001 ECX=54450246 EDX=00000000
ESI=061f0000 EDI=c7300000 EBP=00000000 ESP=00007b88
EIP=7e6005a8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
...

This happens only with SeaBIOS, the old BIOS works!

Regards,
Stefan Weil

[Qemu-devel] Re: PC machine types switched to SeaBIOS/gPXE

[Jan Kiszka]

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

Stefan Weil wrote:
> Anthony Liguori schrieb:
>> Hi,
>>
>> I just wanted to let everyone know that I've switched the PC machine
>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>> by Kevin O'Conner, along with quite a lot of clean up and new feature
>> work.
>>
>> gPXE is the new development tree of etherboot which is now
>> deprecated.  We've done a lot of testing of and while there are a few
>> outstanding issues, almost everything seems to be working okay.
>>
>> Some known issues:
>> o e1000 pxe booting doesn't seem to work
>> o gPXE does not like the slirp tftp server
>> o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
>>
>> I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
>> SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
>> effort to debug.
>>
>> I want to thank everyone who helped make this all happen.  It was a
>> big effort and I think it's going to be a really nice feature for the
>> 0.12.0 release!
>>
> 
> More issues:
> 
> * QEMU crash with all working pxe devices:
> 
> i386-softmmu/qemu -boot n -net nic,model=pcnet -net user -L pc-bios
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x7e6005a8
> 
> EAX=00007b52 EBX=9c730001 ECX=54450246 EDX=00000000
> ESI=061f0000 EDI=c7300000 EBP=00000000 ESP=00007b88
> EIP=7e6005a8 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ...

Yes, this happens when gpxe found no tftp server or boot file (you
didn't specify any) and then tries to restart. This restart seems to go
through the bios which fails to properly reset the context, I bet.

Another issue: model=e1000 doesn't work this way (-boot n), only if you
go via gpxe menu and 'autoboot'. Other nic types seem to be fine.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Alexander Graf]

Anthony Liguori wrote:
> Hi,
>
> I just wanted to let everyone know that I've switched the PC machine
> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
> by Kevin O'Conner, along with quite a lot of clean up and new feature
> work.
>
> gPXE is the new development tree of etherboot which is now
> deprecated.  We've done a lot of testing of and while there are a few
> outstanding issues, almost everything seems to be working okay.
>
> Some known issues:
> o e1000 pxe booting doesn't seem to work
> o gPXE does not like the slirp tftp server
> o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
>
> I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
> SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
> effort to debug.
>
> I want to thank everyone who helped make this all happen.  It was a
> big effort and I think it's going to be a really nice feature for the
> 0.12.0 release!
>

-kernel (w/ Linux) breaks.


With SeaBIOS:

EAX=00001000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00007bae
EIP=00000025 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =1000 00010000 0000ffff 00009300
CS =c900 000c9000 0000ffff 00009b0f
SS =1000 00010000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000fcc00 00000037
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=00000000 CCO=EFLAGS 
----------------
IN:
0x00000000000c9025:  mov    %ax,%ds
0x00000000000c9027:  mov    $0x1000,%ax
0x00000000000c902a:  mov    %ax,%fs
0x00000000000c902c:  mov    $0xc1e0,%ax
0x00000000000c902f:  mov    %ax,%gs
0x00000000000c9031:  mov    $0x0,%eax
0x00000000000c9037:  mov    $0x0,%ecx
0x00000000000c903d:  mov    $0x0,%edx
0x00000000000c9043:  mov    $0x0,%ebx
0x00000000000c9049:  mov    $0xfff0,%esp
0x00000000000c904f:  mov    $0x0,%ebp
0x00000000000c9055:  mov    $0x0,%esi
0x00000000000c905b:  mov    $0x0,%edi
0x00000000000c9061:  ljmp   $0x1020,$0x0

EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fff0
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =1000 00010000 0000ffff 00009300
CS =1020 00010200 0000ffff 00009b0f
SS =1000 00010000 0000ffff 00009300
DS =1000 00010000 0000ffff 00009300
FS =1000 00010000 0000ffff 00009300
GS =c1e0 000c1e00 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000fcc00 00000037
IDT=     00000000 000003ff
CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=00000000 CCO=EFLAGS 
----------------
IN:
0x0000000000010200:  add    %al,(%bx,%si)

############################################
############################################
############################################

With BochBIOS:

EAX=00001000 EBX=00008e10 ECX=0009e080 EDX=00000000
ESI=000e0000 EDI=0000fdba EBP=0000fff2 ESP=0000fff8
EIP=00000025 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =1000 00010000 0000ffff 00009300
CS =c900 000c9000 0000ffff 00009b0f
SS =1000 00010000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000fb867 00000030
IDT=     00000000 000003ff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000055 CCD=00000000 CCO=LOGICW 
----------------
IN:
0x00000000000c9025:  mov    %ax,%ds
0x00000000000c9027:  mov    $0x1000,%ax
0x00000000000c902a:  mov    %ax,%fs
0x00000000000c902c:  mov    $0xa1d8,%ax
0x00000000000c902f:  mov    %ax,%gs
0x00000000000c9031:  mov    $0x0,%eax
0x00000000000c9037:  mov    $0x0,%ecx
0x00000000000c903d:  mov    $0x0,%edx
0x00000000000c9043:  mov    $0x0,%ebx
0x00000000000c9049:  mov    $0xfff0,%esp
0x00000000000c904f:  mov    $0x0,%ebp
0x00000000000c9055:  mov    $0x0,%esi
0x00000000000c905b:  mov    $0x0,%edi
0x00000000000c9061:  ljmp   $0x1020,$0x0

EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fff0
EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =1000 00010000 0000ffff 00009300
CS =1020 00010200 0000ffff 00009b0f
SS =1000 00010000 0000ffff 00009300
DS =1000 00010000 0000ffff 00009300
FS =1000 00010000 0000ffff 00009300
GS =a1d8 000a1d80 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     000fb867 00000030
IDT=     00000000 000003ff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
DR6=ffff0ff0 DR7=00000400
CCS=00000055 CCD=00000000 CCO=LOGICW 
----------------
IN:
0x0000000000010200:  jmp    0x10264

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/02/2009 02:51 PM, Alexander Graf wrote:
> Anthony Liguori wrote:
>    
>> Hi,
>>
>> I just wanted to let everyone know that I've switched the PC machine
>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>> by Kevin O'Conner, along with quite a lot of clean up and new feature
>> work.
>>
>> gPXE is the new development tree of etherboot which is now
>> deprecated.  We've done a lot of testing of and while there are a few
>> outstanding issues, almost everything seems to be working okay.
>>
>> Some known issues:
>> o e1000 pxe booting doesn't seem to work
>> o gPXE does not like the slirp tftp server
>> o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
>>
>> I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
>> SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
>> effort to debug.
>>
>> I want to thank everyone who helped make this all happen.  It was a
>> big effort and I think it's going to be a really nice feature for the
>> 0.12.0 release!
>>
>>      
> -kernel (w/ Linux) breaks.
>    

What do the dumps mean?  when are they taken?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Alexander Graf]

Avi Kivity wrote:
> On 11/02/2009 02:51 PM, Alexander Graf wrote:
>> Anthony Liguori wrote:
>>   
>>> Hi,
>>>
>>> I just wanted to let everyone know that I've switched the PC machine
>>> type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
>>> by Kevin O'Conner, along with quite a lot of clean up and new feature
>>> work.
>>>
>>> gPXE is the new development tree of etherboot which is now
>>> deprecated.  We've done a lot of testing of and while there are a few
>>> outstanding issues, almost everything seems to be working okay.
>>>
>>> Some known issues:
>>> o e1000 pxe booting doesn't seem to work
>>> o gPXE does not like the slirp tftp server
>>> o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
>>>
>>> I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
>>> SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
>>> effort to debug.
>>>
>>> I want to thank everyone who helped make this all happen.  It was a
>>> big effort and I think it's going to be a really nice feature for the
>>> 0.12.0 release!
>>>
>>>      
>> -kernel (w/ Linux) breaks.
>>    
>
> What do the dumps mean?  when are they taken?
>

They are taken with -d in_asm,cpu,int after doing:

$ ./x86_64-softmmu/qemu-system-x86_64 -kernel ../kvm/arch/x86/boot/bzImage

with a fresh checkout from your kvm kernel tree (make defconfig) and a
fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)


They basically mean that with SeaBIOS the Linux loading code is trying
to jump off to zeros while at the same place there is useful data using
pcbios.bin.

Alex

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/02/2009 03:15 PM, Alexander Graf wrote:
>
> They are taken with -d in_asm,cpu,int after doing:
>
> $ ./x86_64-softmmu/qemu-system-x86_64 -kernel ../kvm/arch/x86/boot/bzImage
>
> with a fresh checkout from your kvm kernel tree (make defconfig) and a
> fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)
>
>
> They basically mean that with SeaBIOS the Linux loading code is trying
> to jump off to zeros while at the same place there is useful data using
> pcbios.bin.
>    

Is seabios clobbering memory?  Gleb/Kevin?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Kevin O'Connor]

On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
> On 11/02/2009 03:15 PM, Alexander Graf wrote:
>>
>> They are taken with -d in_asm,cpu,int after doing:
>>
>> $ ./x86_64-softmmu/qemu-system-x86_64 -kernel ../kvm/arch/x86/boot/bzImage
>>
>> with a fresh checkout from your kvm kernel tree (make defconfig) and a
>> fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)
>>
>>
>> They basically mean that with SeaBIOS the Linux loading code is trying
>> to jump off to zeros while at the same place there is useful data using
>> pcbios.bin.
>>    
>
> Is seabios clobbering memory?  Gleb/Kevin?

I have not tested with the -kernel option before.  I believe you may
be running into the clearing of memory that PMM does - see
malloc_finalize() in src/pmm.c.  The PMM spec requires that low memory
be cleared before starting the boot process.

I'll take a closer look tonight.

-Kevin

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
> On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
>    
>> On 11/02/2009 03:15 PM, Alexander Graf wrote:
>>      
>>> They are taken with -d in_asm,cpu,int after doing:
>>>
>>> $ ./x86_64-softmmu/qemu-system-x86_64 -kernel ../kvm/arch/x86/boot/bzImage
>>>
>>> with a fresh checkout from your kvm kernel tree (make defconfig) and a
>>> fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)
>>>
>>>
>>> They basically mean that with SeaBIOS the Linux loading code is trying
>>> to jump off to zeros while at the same place there is useful data using
>>> pcbios.bin.
>>>
>>>        
>> Is seabios clobbering memory?  Gleb/Kevin?
>>      
> I have not tested with the -kernel option before.  I believe you may
> be running into the clearing of memory that PMM does - see
> malloc_finalize() in src/pmm.c.  The PMM spec requires that low memory
> be cleared before starting the boot process.
>
>    

Likely.  Alex, does -kernel use memory below 1MB?  Can it be moved 
elsewhere?

If not, we probably need a protocol where the option rom loads the 
kernel from qemu, rather than qemu poking the kernel into memory.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Alexander Graf]

Avi Kivity wrote:
> On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
>> On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
>>   
>>> On 11/02/2009 03:15 PM, Alexander Graf wrote:
>>>     
>>>> They are taken with -d in_asm,cpu,int after doing:
>>>>
>>>> $ ./x86_64-softmmu/qemu-system-x86_64 -kernel
>>>> ../kvm/arch/x86/boot/bzImage
>>>>
>>>> with a fresh checkout from your kvm kernel tree (make defconfig) and a
>>>> fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)
>>>>
>>>>
>>>> They basically mean that with SeaBIOS the Linux loading code is trying
>>>> to jump off to zeros while at the same place there is useful data
>>>> using
>>>> pcbios.bin.
>>>>
>>>>        
>>> Is seabios clobbering memory?  Gleb/Kevin?
>>>      
>> I have not tested with the -kernel option before.  I believe you may
>> be running into the clearing of memory that PMM does - see
>> malloc_finalize() in src/pmm.c.  The PMM spec requires that low memory
>> be cleared before starting the boot process.
>>
>>    
>
> Likely.  Alex, does -kernel use memory below 1MB?  Can it be moved
> elsewhere?
>
> If not, we probably need a protocol where the option rom loads the
> kernel from qemu, rather than qemu poking the kernel into memory.
>

pc.c:

    } else {
        /* High and recent kernel */
        real_addr    = 0x10000;
        cmdline_addr = 0x20000;
        prot_addr    = 0x100000;
    }

If I'm not totally mistaken, 0x10000 is < 1MB :-).

So yes, I think there should be a fw-conf interface that tells qemu to
reload all volatile option rom regions (which it keeps track of for
reset anyway). We just need to make sure it doesn't overwrite the BIOS
itself, as data in there might have been changed already.

Alex

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/02/2009 04:06 PM, Alexander Graf wrote:
> pc.c:
>      } else {
>          /* High and recent kernel */
>          real_addr    = 0x10000;
>          cmdline_addr = 0x20000;
>          prot_addr    = 0x100000;
>      }
>
> If I'm not totally mistaken, 0x10000 is<  1MB :-).
>
> So yes, I think there should be a fw-conf interface that tells qemu to
> reload all volatile option rom regions (which it keeps track of for
> reset anyway).

Not reload, load.

> We just need to make sure it doesn't overwrite the BIOS
> itself, as data in there might have been changed already.
>    

Well, the bios could tell qemu where to put the kernel using the same 
interface.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Glauber Costa]

On Mon, Nov 02, 2009 at 03:06:45PM +0100, Alexander Graf wrote:
> Avi Kivity wrote:
> > On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
> >> On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
> >>   
> >>> On 11/02/2009 03:15 PM, Alexander Graf wrote:
> >>>     
> >>>> They are taken with -d in_asm,cpu,int after doing:
> >>>>
> >>>> $ ./x86_64-softmmu/qemu-system-x86_64 -kernel
> >>>> ../kvm/arch/x86/boot/bzImage
> >>>>
> >>>> with a fresh checkout from your kvm kernel tree (make defconfig) and a
> >>>> fresh git checkout of qemu (./configure --target-list=x86_64-softmmu)
> >>>>
> >>>>
> >>>> They basically mean that with SeaBIOS the Linux loading code is trying
> >>>> to jump off to zeros while at the same place there is useful data
> >>>> using
> >>>> pcbios.bin.
> >>>>
> >>>>        
> >>> Is seabios clobbering memory?  Gleb/Kevin?
> >>>      
> >> I have not tested with the -kernel option before.  I believe you may
> >> be running into the clearing of memory that PMM does - see
> >> malloc_finalize() in src/pmm.c.  The PMM spec requires that low memory
> >> be cleared before starting the boot process.
> >>
> >>    
> >
> > Likely.  Alex, does -kernel use memory below 1MB?  Can it be moved
> > elsewhere?
> >
> > If not, we probably need a protocol where the option rom loads the
> > kernel from qemu, rather than qemu poking the kernel into memory.
> >
> 
> pc.c:
> 
>     } else {
>         /* High and recent kernel */
>         real_addr    = 0x10000;
>         cmdline_addr = 0x20000;
>         prot_addr    = 0x100000;
>     }
> 
> If I'm not totally mistaken, 0x10000 is < 1MB :-).
> 
> So yes, I think there should be a fw-conf interface that tells qemu to
> reload all volatile option rom regions (which it keeps track of for
> reset anyway). We just need to make sure it doesn't overwrite the BIOS
> itself, as data in there might have been changed already.

Can't we put these data somewhere else, and let our int19 handler copy
it to the right location?

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/09/2009 08:41 PM, Glauber Costa wrote:
>
>> pc.c:
>>
>>      } else {
>>          /* High and recent kernel */
>>          real_addr    = 0x10000;
>>          cmdline_addr = 0x20000;
>>          prot_addr    = 0x100000;
>>      }
>>
>> If I'm not totally mistaken, 0x10000 is<  1MB :-).
>>
>> So yes, I think there should be a fw-conf interface that tells qemu to
>> reload all volatile option rom regions (which it keeps track of for
>> reset anyway). We just need to make sure it doesn't overwrite the BIOS
>> itself, as data in there might have been changed already.
>>      
> Can't we put these data somewhere else, and let our int19 handler copy
> it to the right location?
>    

Anywhere you put it the bios has a right to trample.  Of course our bios 
(and its maintainer) are cooperative, but there's not reason to impose 
on that if we can do the right thing and load the data at the right moment.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Alexander Graf]

On 10.11.2009, at 14:02, Avi Kivity wrote:

> On 11/09/2009 08:41 PM, Glauber Costa wrote:
>>
>>> pc.c:
>>>
>>>     } else {
>>>         /* High and recent kernel */
>>>         real_addr    = 0x10000;
>>>         cmdline_addr = 0x20000;
>>>         prot_addr    = 0x100000;
>>>     }
>>>
>>> If I'm not totally mistaken, 0x10000 is<  1MB :-).
>>>
>>> So yes, I think there should be a fw-conf interface that tells  
>>> qemu to
>>> reload all volatile option rom regions (which it keeps track of for
>>> reset anyway). We just need to make sure it doesn't overwrite the  
>>> BIOS
>>> itself, as data in there might have been changed already.
>>>
>> Can't we put these data somewhere else, and let our int19 handler  
>> copy
>> it to the right location?
>>
>
> Anywhere you put it the bios has a right to trample.  Of course our  
> bios (and its maintainer) are cooperative, but there's not reason to  
> impose on that if we can do the right thing and load the data at the  
> right moment.

Right. The only thing we're missing is soft breakpoints set in gdb  
when running the guest with -s -S, as the guest kernel just isn't  
there by then yet.

But I guess we can live without that feature, as long as the rest works.


Alex

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/10/2009 03:03 PM, Alexander Graf wrote:
>> Anywhere you put it the bios has a right to trample.  Of course our 
>> bios (and its maintainer) are cooperative, but there's not reason to 
>> impose on that if we can do the right thing and load the data at the 
>> right moment.
>
>
> Right. The only thing we're missing is soft breakpoints set in gdb 
> when running the guest with -s -S, as the guest kernel just isn't 
> there by then yet.

Copying things around in int 19 would also break this.

>
> But I guess we can live without that feature, as long as the rest works.
>

You can put a hardware breakpoint on the ELF entry point and then place 
your soft breakpoints.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Alexander Graf]

On 10.11.2009, at 14:07, Avi Kivity wrote:

> On 11/10/2009 03:03 PM, Alexander Graf wrote:
>>> Anywhere you put it the bios has a right to trample.  Of course  
>>> our bios (and its maintainer) are cooperative, but there's not  
>>> reason to impose on that if we can do the right thing and load the  
>>> data at the right moment.
>>
>>
>> Right. The only thing we're missing is soft breakpoints set in gdb  
>> when running the guest with -s -S, as the guest kernel just isn't  
>> there by then yet.
>
> Copying things around in int 19 would also break this.

Yeah, I'm not pro the copying idea. This was more of a general remark  
wrt what regressions we introduce.

>> But I guess we can live without that feature, as long as the rest  
>> works.
>>
>
> You can put a hardware breakpoint on the ELF entry point and then  
> place your soft breakpoints.

In fact when you have a working hardware breakpoint implementation you  
can still set the breakpoint with -s -S.

Alex

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Kevin O'Connor]

On Mon, Nov 02, 2009 at 03:56:08PM +0200, Avi Kivity wrote:
> On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
>> On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
>>> Is seabios clobbering memory?  Gleb/Kevin?
>> I have not tested with the -kernel option before.  I believe you may
>> be running into the clearing of memory that PMM does - see
>> malloc_finalize() in src/pmm.c.  The PMM spec requires that low memory
>> be cleared before starting the boot process.
> Likely.  Alex, does -kernel use memory below 1MB?  Can it be moved  
> elsewhere?

I've confirmed that commenting out the memset in malloc_finalize()
fixes the reported problem.

Removing the memset is probably okay for the short-term, but it would
contradict the PMM spec, so we'll need some kind of long-term
solution.

Also, SeaBIOS wont clear high-memory, but nothing stops SeaBIOS from
using high memory for scratch space during init.

> If not, we probably need a protocol where the option rom loads the  
> kernel from qemu, rather than qemu poking the kernel into memory.

Yes, I'd prefer to see this.  In earlier emails, Gleb made a reference
to a qemu-cfg "stream" interface that is used for acpi tables - maybe
the kernel could be put in one of the streams and the rom could copy
it into ram on boot.

Let me know what you wish to do.
-Kevin

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Alexander Graf]

On 03.11.2009, at 05:50, Kevin O'Connor wrote:

> On Mon, Nov 02, 2009 at 03:56:08PM +0200, Avi Kivity wrote:
>> On 11/02/2009 03:51 PM, Kevin O'Connor wrote:
>>> On Mon, Nov 02, 2009 at 03:32:54PM +0200, Avi Kivity wrote:
>>>> Is seabios clobbering memory?  Gleb/Kevin?
>>> I have not tested with the -kernel option before.  I believe you may
>>> be running into the clearing of memory that PMM does - see
>>> malloc_finalize() in src/pmm.c.  The PMM spec requires that low  
>>> memory
>>> be cleared before starting the boot process.
>> Likely.  Alex, does -kernel use memory below 1MB?  Can it be moved
>> elsewhere?
>
> I've confirmed that commenting out the memset in malloc_finalize()
> fixes the reported problem.
>
> Removing the memset is probably okay for the short-term, but it would
> contradict the PMM spec, so we'll need some kind of long-term
> solution.
>
> Also, SeaBIOS wont clear high-memory, but nothing stops SeaBIOS from
> using high memory for scratch space during init.
>
>> If not, we probably need a protocol where the option rom loads the
>> kernel from qemu, rather than qemu poking the kernel into memory.
>
> Yes, I'd prefer to see this.  In earlier emails, Gleb made a reference
> to a qemu-cfg "stream" interface that is used for acpi tables - maybe
> the kernel could be put in one of the streams and the rom could copy
> it into ram on boot.

I don't think streaming is the right approach here. Streaming would  
mean the rom had to copy, which again either a lot of PIO accesses  
(slow!) or a complicated DMA interface.

I'd rather go for a RAM poking approach. As soon as the option rom is  
loaded, it calls qemu via PIO telling it to "load the kernel in RAM  
now" and as of the next instruction everything's in place at the  
determined addresses. It's not like we could do anything about the  
physical layout in the option rom anyways, usually the kernel tells us  
what that looks like.

Alex

>
> Let me know what you wish to do.
> -Kevin

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/03/2009 06:57 AM, Alexander Graf wrote:
>> Yes, I'd prefer to see this.  In earlier emails, Gleb made a reference
>> to a qemu-cfg "stream" interface that is used for acpi tables - maybe
>> the kernel could be put in one of the streams and the rom could copy
>> it into ram on boot.
>
>
> I don't think streaming is the right approach here. Streaming would 
> mean the rom had to copy, which again either a lot of PIO accesses 
> (slow!) or a complicated DMA interface.

A rep/ins instruction will take one exit/page so it won't be 
particularly slow.

> I'd rather go for a RAM poking approach. As soon as the option rom is 
> loaded, it calls qemu via PIO telling it to "load the kernel in RAM 
> now" and as of the next instruction everything's in place at the 
> determined addresses. It's not like we could do anything about the 
> physical layout in the option rom anyways, usually the kernel tells us 
> what that looks like.

That works too, but if firmware config can use rep/ins, that's one less 
interface we have to add.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Kevin O'Connor]

On Tue, Nov 03, 2009 at 07:01:52AM +0200, Avi Kivity wrote:
> That works too, but if firmware config can use rep/ins, that's one less  
> interface we have to add.

The following patch to seabios seems to work.  I'm not sure if there
are any special implications to qemu.

-Kevin



--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -23,8 +23,7 @@ qemu_cfg_select(u16 f)
 static void
 qemu_cfg_read(u8 *buf, int len)
 {
-    while (len--)
-        *(buf++) = inb(PORT_QEMU_CFG_DATA);
+    insb(PORT_QEMU_CFG_DATA, buf, len);
 }
 
 static void

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/03/2009 08:02 AM, Kevin O'Connor wrote:
> On Tue, Nov 03, 2009 at 07:01:52AM +0200, Avi Kivity wrote:
>    
>> That works too, but if firmware config can use rep/ins, that's one less
>> interface we have to add.
>>      
> The following patch to seabios seems to work.  I'm not sure if there
> are any special implications to qemu.
>
> -Kevin
>
>
>
> --- a/src/paravirt.c
> +++ b/src/paravirt.c
> @@ -23,8 +23,7 @@ qemu_cfg_select(u16 f)
>   static void
>   qemu_cfg_read(u8 *buf, int len)
>   {
> -    while (len--)
> -        *(buf++) = inb(PORT_QEMU_CFG_DATA);
> +    insb(PORT_QEMU_CFG_DATA, buf, len);
>   }
>    

Should make sure to use the 32-bit address size version so we use ecx, 
not cx, in case len doesn't fit in 16 bits.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Kevin O'Connor]

On Tue, Nov 03, 2009 at 08:08:25AM +0200, Avi Kivity wrote:
> On 11/03/2009 08:02 AM, Kevin O'Connor wrote:
>> On Tue, Nov 03, 2009 at 07:01:52AM +0200, Avi Kivity wrote:
>> --- a/src/paravirt.c
>> +++ b/src/paravirt.c
>> @@ -23,8 +23,7 @@ qemu_cfg_select(u16 f)
>>   static void
>>   qemu_cfg_read(u8 *buf, int len)
>>   {
>> -    while (len--)
>> -        *(buf++) = inb(PORT_QEMU_CFG_DATA);
>> +    insb(PORT_QEMU_CFG_DATA, buf, len);
>>   }
>
> Should make sure to use the 32-bit address size version so we use ecx,  
> not cx, in case len doesn't fit in 16 bits.

I think SeaBIOS has the 32bit version as of commit 7edaa658:

static inline void insb(u16 port, u8 *data, u32 count) {
    asm volatile("rep insb (%%dx), %%es:(%%edi)"
                 : "+c"(count), "+D"(data) : "d"(port) : "memory");
}

-Kevin

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Avi Kivity]

On 11/03/2009 06:50 AM, Kevin O'Connor wrote:
>> If not, we probably need a protocol where the option rom loads the
>> kernel from qemu, rather than qemu poking the kernel into memory.
>>      
> Yes, I'd prefer to see this.  In earlier emails, Gleb made a reference
> to a qemu-cfg "stream" interface that is used for acpi tables - maybe
> the kernel could be put in one of the streams and the rom could copy
> it into ram on boot.
>
> Let me know what you wish to do.
>    

I think the consensus is that seabios is correct and -kernel needs to be 
fixed.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Gleb Natapov]

On Mon, Nov 02, 2009 at 01:51:56PM +0100, Alexander Graf wrote:
> Anthony Liguori wrote:
> > Hi,
> >
> > I just wanted to let everyone know that I've switched the PC machine
> > type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
> > by Kevin O'Conner, along with quite a lot of clean up and new feature
> > work.
> >
> > gPXE is the new development tree of etherboot which is now
> > deprecated.  We've done a lot of testing of and while there are a few
> > outstanding issues, almost everything seems to be working okay.
> >
> > Some known issues:
> > o e1000 pxe booting doesn't seem to work
> > o gPXE does not like the slirp tftp server
> > o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
> >
> > I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
> > SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
> > effort to debug.
> >
> > I want to thank everyone who helped make this all happen.  It was a
> > big effort and I think it's going to be a really nice feature for the
> > 0.12.0 release!
> >
> 
> -kernel (w/ Linux) breaks.
> 
>From you mail I don't understand if it works with Bochs BIOS. Does it?

> 
> With SeaBIOS:
> 
> EAX=00001000 EBX=00000000 ECX=00000000 EDX=00000000
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00007bae
> EIP=00000025 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =1000 00010000 0000ffff 00009300
> CS =c900 000c9000 0000ffff 00009b0f
> SS =1000 00010000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT=     000fcc00 00000037
> IDT=     00000000 000003ff
> CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> DR6=ffff0ff0 DR7=00000400
> CCS=00000000 CCD=00000000 CCO=EFLAGS 
> ----------------
> IN:
> 0x00000000000c9025:  mov    %ax,%ds
> 0x00000000000c9027:  mov    $0x1000,%ax
> 0x00000000000c902a:  mov    %ax,%fs
> 0x00000000000c902c:  mov    $0xc1e0,%ax
> 0x00000000000c902f:  mov    %ax,%gs
> 0x00000000000c9031:  mov    $0x0,%eax
> 0x00000000000c9037:  mov    $0x0,%ecx
> 0x00000000000c903d:  mov    $0x0,%edx
> 0x00000000000c9043:  mov    $0x0,%ebx
> 0x00000000000c9049:  mov    $0xfff0,%esp
> 0x00000000000c904f:  mov    $0x0,%ebp
> 0x00000000000c9055:  mov    $0x0,%esi
> 0x00000000000c905b:  mov    $0x0,%edi
> 0x00000000000c9061:  ljmp   $0x1020,$0x0
> 
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fff0
> EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =1000 00010000 0000ffff 00009300
> CS =1020 00010200 0000ffff 00009b0f
> SS =1000 00010000 0000ffff 00009300
> DS =1000 00010000 0000ffff 00009300
> FS =1000 00010000 0000ffff 00009300
> GS =c1e0 000c1e00 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT=     000fcc00 00000037
> IDT=     00000000 000003ff
> CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> DR6=ffff0ff0 DR7=00000400
> CCS=00000000 CCD=00000000 CCO=EFLAGS 
> ----------------
> IN:
> 0x0000000000010200:  add    %al,(%bx,%si)
> 
> ############################################
> ############################################
> ############################################
> 
> With BochBIOS:
> 
> EAX=00001000 EBX=00008e10 ECX=0009e080 EDX=00000000
> ESI=000e0000 EDI=0000fdba EBP=0000fff2 ESP=0000fff8
> EIP=00000025 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =1000 00010000 0000ffff 00009300
> CS =c900 000c9000 0000ffff 00009b0f
> SS =1000 00010000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT=     000fb867 00000030
> IDT=     00000000 000003ff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> DR6=ffff0ff0 DR7=00000400
> CCS=00000055 CCD=00000000 CCO=LOGICW 
> ----------------
> IN:
> 0x00000000000c9025:  mov    %ax,%ds
> 0x00000000000c9027:  mov    $0x1000,%ax
> 0x00000000000c902a:  mov    %ax,%fs
> 0x00000000000c902c:  mov    $0xa1d8,%ax
> 0x00000000000c902f:  mov    %ax,%gs
> 0x00000000000c9031:  mov    $0x0,%eax
> 0x00000000000c9037:  mov    $0x0,%ecx
> 0x00000000000c903d:  mov    $0x0,%edx
> 0x00000000000c9043:  mov    $0x0,%ebx
> 0x00000000000c9049:  mov    $0xfff0,%esp
> 0x00000000000c904f:  mov    $0x0,%ebp
> 0x00000000000c9055:  mov    $0x0,%esi
> 0x00000000000c905b:  mov    $0x0,%edi
> 0x00000000000c9061:  ljmp   $0x1020,$0x0
> 
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fff0
> EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =1000 00010000 0000ffff 00009300
> CS =1020 00010200 0000ffff 00009b0f
> SS =1000 00010000 0000ffff 00009300
> DS =1000 00010000 0000ffff 00009300
> FS =1000 00010000 0000ffff 00009300
> GS =a1d8 000a1d80 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT=     000fb867 00000030
> IDT=     00000000 000003ff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> DR6=ffff0ff0 DR7=00000400
> CCS=00000055 CCD=00000000 CCO=LOGICW 
> ----------------
> IN:
> 0x0000000000010200:  jmp    0x10264

--
			Gleb.

Re: [Qemu-devel] PC machine types switched to SeaBIOS/gPXE

[Gleb Natapov]

On Mon, Nov 02, 2009 at 04:51:47PM +0200, Gleb Natapov wrote:
> On Mon, Nov 02, 2009 at 01:51:56PM +0100, Alexander Graf wrote:
> > Anthony Liguori wrote:
> > > Hi,
> > >
> > > I just wanted to let everyone know that I've switched the PC machine
> > > type to SeaBIOS and gPXE.  SeaBIOS is a port of the Bochs BIOS to GCC,
> > > by Kevin O'Conner, along with quite a lot of clean up and new feature
> > > work.
> > >
> > > gPXE is the new development tree of etherboot which is now
> > > deprecated.  We've done a lot of testing of and while there are a few
> > > outstanding issues, almost everything seems to be working okay.
> > >
> > > Some known issues:
> > > o e1000 pxe booting doesn't seem to work
> > > o gPXE does not like the slirp tftp server
> > > o SeaBIOS doesn't support CPU hotplug (not an issue for upstream qemu)
> > >
> > > I've renamed the old pcbios to pcbios.bin.  If you suspect a bug in
> > > SeaBIOS, you can use "-bios pcbios.bin" to try with the old BIOS in an
> > > effort to debug.
> > >
> > > I want to thank everyone who helped make this all happen.  It was a
> > > big effort and I think it's going to be a really nice feature for the
> > > 0.12.0 release!
> > >
> > 
> > -kernel (w/ Linux) breaks.
> > 
> From you mail I don't understand if it works with Bochs BIOS. Does it?
> 
Sorry. Disregard this. Saw discussion that follows.

> > 
> > With SeaBIOS:
> > 
> > EAX=00001000 EBX=00000000 ECX=00000000 EDX=00000000
> > ESI=00000000 EDI=00000000 EBP=00000000 ESP=00007bae
> > EIP=00000025 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> > ES =1000 00010000 0000ffff 00009300
> > CS =c900 000c9000 0000ffff 00009b0f
> > SS =1000 00010000 0000ffff 00009300
> > DS =0000 00000000 0000ffff 00009300
> > FS =0000 00000000 0000ffff 00009300
> > GS =0000 00000000 0000ffff 00009300
> > LDT=0000 00000000 0000ffff 00008200
> > TR =0000 00000000 0000ffff 00008b00
> > GDT=     000fcc00 00000037
> > IDT=     00000000 000003ff
> > CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
> > DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> > DR6=ffff0ff0 DR7=00000400
> > CCS=00000000 CCD=00000000 CCO=EFLAGS 
> > ----------------
> > IN:
> > 0x00000000000c9025:  mov    %ax,%ds
> > 0x00000000000c9027:  mov    $0x1000,%ax
> > 0x00000000000c902a:  mov    %ax,%fs
> > 0x00000000000c902c:  mov    $0xc1e0,%ax
> > 0x00000000000c902f:  mov    %ax,%gs
> > 0x00000000000c9031:  mov    $0x0,%eax
> > 0x00000000000c9037:  mov    $0x0,%ecx
> > 0x00000000000c903d:  mov    $0x0,%edx
> > 0x00000000000c9043:  mov    $0x0,%ebx
> > 0x00000000000c9049:  mov    $0xfff0,%esp
> > 0x00000000000c904f:  mov    $0x0,%ebp
> > 0x00000000000c9055:  mov    $0x0,%esi
> > 0x00000000000c905b:  mov    $0x0,%edi
> > 0x00000000000c9061:  ljmp   $0x1020,$0x0
> > 
> > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
> > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fff0
> > EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> > ES =1000 00010000 0000ffff 00009300
> > CS =1020 00010200 0000ffff 00009b0f
> > SS =1000 00010000 0000ffff 00009300
> > DS =1000 00010000 0000ffff 00009300
> > FS =1000 00010000 0000ffff 00009300
> > GS =c1e0 000c1e00 0000ffff 00009300
> > LDT=0000 00000000 0000ffff 00008200
> > TR =0000 00000000 0000ffff 00008b00
> > GDT=     000fcc00 00000037
> > IDT=     00000000 000003ff
> > CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
> > DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> > DR6=ffff0ff0 DR7=00000400
> > CCS=00000000 CCD=00000000 CCO=EFLAGS 
> > ----------------
> > IN:
> > 0x0000000000010200:  add    %al,(%bx,%si)
> > 
> > ############################################
> > ############################################
> > ############################################
> > 
> > With BochBIOS:
> > 
> > EAX=00001000 EBX=00008e10 ECX=0009e080 EDX=00000000
> > ESI=000e0000 EDI=0000fdba EBP=0000fff2 ESP=0000fff8
> > EIP=00000025 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> > ES =1000 00010000 0000ffff 00009300
> > CS =c900 000c9000 0000ffff 00009b0f
> > SS =1000 00010000 0000ffff 00009300
> > DS =0000 00000000 0000ffff 00009300
> > FS =0000 00000000 0000ffff 00009300
> > GS =0000 00000000 0000ffff 00009300
> > LDT=0000 00000000 0000ffff 00008200
> > TR =0000 00000000 0000ffff 00008b00
> > GDT=     000fb867 00000030
> > IDT=     00000000 000003ff
> > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> > DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> > DR6=ffff0ff0 DR7=00000400
> > CCS=00000055 CCD=00000000 CCO=LOGICW 
> > ----------------
> > IN:
> > 0x00000000000c9025:  mov    %ax,%ds
> > 0x00000000000c9027:  mov    $0x1000,%ax
> > 0x00000000000c902a:  mov    %ax,%fs
> > 0x00000000000c902c:  mov    $0xa1d8,%ax
> > 0x00000000000c902f:  mov    %ax,%gs
> > 0x00000000000c9031:  mov    $0x0,%eax
> > 0x00000000000c9037:  mov    $0x0,%ecx
> > 0x00000000000c903d:  mov    $0x0,%edx
> > 0x00000000000c9043:  mov    $0x0,%ebx
> > 0x00000000000c9049:  mov    $0xfff0,%esp
> > 0x00000000000c904f:  mov    $0x0,%ebp
> > 0x00000000000c9055:  mov    $0x0,%esi
> > 0x00000000000c905b:  mov    $0x0,%edi
> > 0x00000000000c9061:  ljmp   $0x1020,$0x0
> > 
> > EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
> > ESI=00000000 EDI=00000000 EBP=00000000 ESP=0000fff0
> > EIP=00000000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> > ES =1000 00010000 0000ffff 00009300
> > CS =1020 00010200 0000ffff 00009b0f
> > SS =1000 00010000 0000ffff 00009300
> > DS =1000 00010000 0000ffff 00009300
> > FS =1000 00010000 0000ffff 00009300
> > GS =a1d8 000a1d80 0000ffff 00009300
> > LDT=0000 00000000 0000ffff 00008200
> > TR =0000 00000000 0000ffff 00008b00
> > GDT=     000fb867 00000030
> > IDT=     00000000 000003ff
> > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> > DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000
> > DR6=ffff0ff0 DR7=00000400
> > CCS=00000055 CCD=00000000 CCO=LOGICW 
> > ----------------
> > IN:
> > 0x0000000000010200:  jmp    0x10264
> 
> --
> 			Gleb.

--
			Gleb.