pc-bios/bios.bin - where it comes from?

DISCUSSION Michael Tokarev 4 participants 8 messages Mar 4, 2010 – Mar 5, 2010 KVM

lore

Share & tools

lore

Michael Tokarev

author

2010-03-04 22:46 UTC #0 lore raw

Hello.

There are a few bugs filed about an.. interesting behavour. For example:

http://www.mail-archive.com/[email protected]/msg29834.html
https://bugs.launchpad.net/qemu/+bug/513273

After quite some mix-n-matching, at least on my test machine, I can say that the issue gets triggered by seabios. When using pc-bios/bios.bin everything is ok. But when using any other bios.bin, even downloading seabios-0.5.1.tar.gz and building it - on a debian lenny system anyway - by running `make', the problem triggers.

I tried different versions/variations of vgabios.bin (it's only -vga std which triggers the issue so far), including 0.6b and 0.6c built from sources, vgabios.bin from debian packages (0.6b and 0.6c), and the one included in qemu-0.12.3.tar.gz. And my conclusion so far is that vgabios.bin has exactly _no_ effect on the issue.

But when using bios.bin from qemu-kvm-0.12.3.tar.gz, and _only_ that bios.bin, the problem goes away.

So the question arises: where that pc-bios/bios.bin comes from into qemu-0.12.3.tar.gz? It is either built from some other sources (not from seabios-0.5.1), or built with some extra/different compiler/linker options, or built using different compiler/linker.

This is partially confirmed on ubuntu as well, but, as far as I understand, there the behavour is different with different versions of vgabios.

In case it's not clear: I'm testing qemu-kvm-0.12.3; bios.bin is the same in qemu-0.12.3 and qemu-kvm-0.12.3.

BTW, is there any reason preventing updating vgabios to 0.6c version - the latest released one?

Thanks!

/mjt

Anthony Liguori

2010-03-05 03:50 UTC #1 lore raw

Quoted 23 lines · Michael Tokarev

Hello.
There are a few bugs filed about an.. interesting behavour. For example:
http://www.mail-archive.com/[email protected]/msg29834.html
https://bugs.launchpad.net/qemu/+bug/513273
After quite some mix-n-matching, at least on my test machine, I can say that the issue gets triggered by seabios. When using pc-bios/bios.bin everything is ok. But when using any other bios.bin, even downloading seabios-0.5.1.tar.gz and building it - on a debian lenny system anyway - by running `make', the problem triggers.
I tried different versions/variations of vgabios.bin (it's only -vga std which triggers the issue so far), including 0.6b and 0.6c built from sources, vgabios.bin from debian packages (0.6b and 0.6c), and the one included in qemu-0.12.3.tar.gz. And my conclusion so far is that vgabios.bin has exactly _no_ effect on the issue.

Quoted 3 lines

But when using bios.bin from qemu-kvm-0.12.3.tar.gz, and _only_ that bios.bin, the problem goes away.

pc-bios/bios.bin gets built from roms/seabios.

We don't ship seabios 0.5.1 in 0.12.3, we ship 0.5.1-stable which is two commits ahead of 0.5.1.

Quoted 10 lines

So the question arises: where that pc-bios/bios.bin comes from into qemu-0.12.3.tar.gz? It is either built from some other sources (not from seabios-0.5.1), or built with some extra/different compiler/linker options, or built using different compiler/linker.
This is partially confirmed on ubuntu as well, but, as far as I understand, there the behavour is different with different versions of vgabios.

One of the reasons we include a git submodule and the source for the bios is so that distributors don't have to deal with building the packages independently. Morale of the story is, just use the source we ship and don't try to be more clever than that :-)

Quoted 6 lines

In case it's not clear: I'm testing qemu-kvm-0.12.3; bios.bin is the same in qemu-0.12.3 and qemu-kvm-0.12.3.
BTW, is there any reason preventing updating vgabios to 0.6c version - the latest released one?

There's no compelling improvement in 0.6c and updating vgabios is not something I'm eager to do unless there's a strong justification.

Regards,

Anthony Liguori

Quoted 8 lines

Thanks!
/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Michael Tokarev

author

2010-03-05 09:17 UTC #2 lore raw

Quoted 9 lines · Anthony Liguori

Quoted 8 lines · Michael Tokarev
Hello.
There are a few bugs filed about an.. interesting
behavour. For example:
http://www.mail-archive.com/[email protected]/msg29834.html
https://bugs.launchpad.net/qemu/+bug/513273

[]

Quoted 4 lines

pc-bios/bios.bin gets built from roms/seabios.
We don't ship seabios 0.5.1 in 0.12.3, we ship 0.5.1-stable which is two commits ahead of 0.5.1.

[]

Quoted 6 lines

One of the reasons we include a git submodule and the source for the bios is so that distributors don't have to deal with building the packages independently. Morale of the story is, just use the source we ship and don't try to be more clever than that :-)
Quoted 1 line
In case it's not clear: I'm testing qemu-kvm-0.12.3;

^^^

Quoted 1 line

Quoted 1 line
bios.bin is the same in qemu-0.12.3 and qemu-kvm-0.12.3.

The thing is that roms/seabios directory is _empty_ in qemu-KVM-0.12.3.tar.gz. So I can't use the sources you (the qemu-kvm team anyway) ship because there's no shipped sources, so I have to try to be clever and find a way to deal with the issue.

But now when you mentioned it and I _finally_ found the bios source in qemu-0.12.3, maybe I'll be even more clever and will patch qemu-kvm with bits missing in it from qemu-0.12.3. Ugly but at least doable.

Quoted 5 lines

Quoted 2 lines
BTW, is there any reason preventing updating vgabios to 0.6c version - the latest released one?
There's no compelling improvement in 0.6c and updating vgabios is not something I'm eager to do unless there's a strong justification.

Maybe wider testing in debian and/or ubuntu is a good justification? :)

Thanks!

/mjt

Anthony Liguori

2010-03-05 13:56 UTC #3 lore raw

Quoted 2 lines · Michael Tokarev

The thing is that roms/seabios directory is _empty_ in qemu-KVM-0.12.3.tar.gz.

That's a mistake as I don't think that was Avi/Marcelo's intention.

Quoted 10 lines

So I can't use the sources you
(the qemu-kvm team anyway) ship because there's no shipped sources, so I have to try to be clever and find a way to deal with the issue.
But now when you mentioned it and I _finally_ found the bios source in qemu-0.12.3, maybe I'll be even more clever and will patch qemu-kvm with bits missing in it from qemu-0.12.3. Ugly but at least doable.

The qemu-kvm tarball was generated incorrectly. To regenerate it correctly, you would do:

$ git clone git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git qemu-kvm-0.12.3.1
$ cd qemu-kvm-0.12.3.1
$ git submodule update --init
$ rm -rf .git roms/seabios/.git roms/vgabios/.git
$ echo '0.12.3.1' > VERSION

Ideally, Avi/Marcelo will do a 0.12.3.1 to fix this.

Regards,

Anthony Liguori

Michael Tokarev

author

2010-03-05 14:55 UTC #4 lore raw

Quoted 5 lines · Anthony Liguori

Quoted 2 lines · Michael Tokarev
The thing is that roms/seabios directory is _empty_ in qemu-KVM-0.12.3.tar.gz.
That's a mistake as I don't think that was Avi/Marcelo's intention.

It's this way since 0.12.0. When 0.12 come out similar question were asked and Avi promised to fix this in a next release..

[]

Quoted 1 line

Ideally, Avi/Marcelo will do a 0.12.3.1 to fix this.

Thanks!

/mjt

Gerd Hoffmann

2010-03-05 12:40 UTC #5 lore raw

In reply to Anthony Liguori

Hi,

Quoted 2 lines

Quoted 2 lines
BTW, is there any reason preventing updating vgabios to 0.6c version - the latest released one?

Yes. It expects some new bochs vbe interface bits being present. qemu doesn't provide them (yet), thus it simply doesn't work.

Quoted 2 lines

There's no compelling improvement in 0.6c and updating vgabios is not something I'm eager to do unless there's a strong justification.

Oh, there is one noticable improvement (patch attached, cherry-picked from vgabios cvs). vgabios can pick the lfb address from pci config space now. This in turn allows us to kill the lfb mapping at hardcoded address 0xe0000000 (except for isapc).

cheers,
Gerd

From 31740228eccdb2b3f96d9f9ce1d65f947d2b744b Mon Sep 17 00:00:00 2001
Subject: use VBE LFB address from PCI base address if present

Make vgabios lookup the lfb address in pci config space instead of using the hard-coded address 0xe0000000.

clext.c +2 ~~-49~~

index c7a2ad0..b0b6834 100644
@@ -948,7 +948,8 @@ cirrus_vesa_01h_3:
   ;; 32-bit LFB address
   xor ax, ax
   stosw
-  call cirrus_get_lfb_addr
+  mov ax, #0x1013 ;; vendor Cirrus
+  call _pci_get_lfb_addr
   stosw
   or ax, ax
   jz cirrus_vesa_01h_4

@@ -1293,54 +1294,6 @@ cgm_2:
 cgm_3:
   ret
 
-  ; get LFB address
-  ; out - ax:LFB address (high 16 bit)
-  ;; NOTE - may be called in protected mode
-cirrus_get_lfb_addr:
-  push cx
-  push dx
-  push eax
-    xor cx, cx
-    mov dl, #0x00
-    call cirrus_pci_read
-    cmp ax, #0xffff
-    jz cirrus_get_lfb_addr_5
- cirrus_get_lfb_addr_3:
-    mov dl, #0x00
-    call cirrus_pci_read
-    cmp ax, #0x1013 ;; cirrus
-    jz cirrus_get_lfb_addr_4
-    add cx, #0x8
-    cmp cx, #0x200 ;; search bus #0 and #1
-    jb cirrus_get_lfb_addr_3
- cirrus_get_lfb_addr_5:
-    xor dx, dx ;; no LFB
-    jmp cirrus_get_lfb_addr_6
- cirrus_get_lfb_addr_4:
-    mov dl, #0x10 ;; I/O space #0
-    call cirrus_pci_read
-    test ax, #0xfff1
-    jnz cirrus_get_lfb_addr_5
-    shr eax, #16
-    mov dx, ax ;; LFB address
- cirrus_get_lfb_addr_6:
-  pop eax
-  mov ax, dx
-  pop dx
-  pop cx
-  ret
-
-cirrus_pci_read:
-  mov eax, #0x00800000
-  mov ax, cx
-  shl eax, #8
-  mov al, dl
-  mov dx, #0xcf8
-  out dx, eax
-  add dl, #4
-  in  eax, dx
-  ret
-
 ;; out - al:bytes per pixel
 cirrus_get_bpp_bytes:
   push dx

vbe.c +9 -4

index 87f7414..8af5255 100644
@@ -888,32 +888,37 @@ Bit16u *AX;Bit16u CX; Bit16u ES;Bit16u DI;
         ModeInfoBlock     info;
         ModeInfoListItem  *cur_info;
         Boolean           using_lfb;
+        Bit16u            lfb_addr;
 
 #ifdef DEBUG
         printf("VBE vbe_biosfn_return_mode_information ES%x DI%x CX%x\n",ES,DI,CX);
 #endif
 
         using_lfb=((CX & VBE_MODE_LINEAR_FRAME_BUFFER) == VBE_MODE_LINEAR_FRAME_BUFFER);
-        
+
         CX = (CX & 0x1ff);
-        
+
         cur_info = mode_info_find_mode(CX, using_lfb, &cur_info);
 
         if (cur_info != 0)
         {
 #ifdef DEBUG
                 printf("VBE found mode %x\n",CX);
-#endif        
+#endif
                 memsetb(ss, &info, 0, sizeof(ModeInfoBlock));
                 memcpyb(ss, &info, 0xc000, &(cur_info->info), sizeof(ModeInfoBlockCompact));
                 if (using_lfb) {
                   info.NumberOfBanks = 1;
                 }
+                lfb_addr = pci_get_lfb_addr(0x1234); // experimental vendor
+                if (lfb_addr > 0) {
+                  info.PhysBasePtr = ((Bit32u)lfb_addr << 16);
+                }
                 if (info.WinAAttributes & VBE_WINDOW_ATTRIBUTE_RELOCATABLE) {
                   info.WinFuncPtr = 0xC0000000UL;
                   *(Bit16u *)&(info.WinFuncPtr) = (Bit16u)(dispi_set_bank_farcall);
                 }
-                
+
                 result = 0x4f;
         }
         else

vgabios.c +58 -0

64 lines not on this page · raw message

Signature · 1 line

1.6.6.1

Aurelien Jarno

2010-03-05 13:39 UTC #6 lore raw

In reply to Anthony Liguori

Quoted 44 lines · Anthony Liguori

Quoted 23 lines · Michael Tokarev
Hello.
There are a few bugs filed about an.. interesting behavour. For example:
http://www.mail-archive.com/[email protected]/msg29834.html
https://bugs.launchpad.net/qemu/+bug/513273
After quite some mix-n-matching, at least on my test machine, I can say that the issue gets triggered by seabios. When using pc-bios/bios.bin everything is ok. But when using any other bios.bin, even downloading seabios-0.5.1.tar.gz and building it - on a debian lenny system anyway - by running `make', the problem triggers.
I tried different versions/variations of vgabios.bin (it's only -vga std which triggers the issue so far), including 0.6b and 0.6c built from sources, vgabios.bin from debian packages (0.6b and 0.6c), and the one included in qemu-0.12.3.tar.gz. And my conclusion so far is that vgabios.bin has exactly _no_ effect on the issue.
Quoted 3 lines
But when using bios.bin from qemu-kvm-0.12.3.tar.gz, and _only_ that bios.bin, the problem goes away.
pc-bios/bios.bin gets built from roms/seabios.
We don't ship seabios 0.5.1 in 0.12.3, we ship 0.5.1-stable which is two commits ahead of 0.5.1.
Quoted 10 lines
So the question arises: where that pc-bios/bios.bin comes from into qemu-0.12.3.tar.gz? It is either built from some other sources (not from seabios-0.5.1), or built with some extra/different compiler/linker options, or built using different compiler/linker.
This is partially confirmed on ubuntu as well, but, as far as I understand, there the behavour is different with different versions of vgabios.

Quoted 5 lines

One of the reasons we include a git submodule and the source for the bios is so that distributors don't have to deal with building the packages independently. Morale of the story is, just use the source we ship and don't try to be more clever than that :-)

This is exactly what distribution usually fight about: same code in different packages, but with subtle differences. If every software was like that, we would not have shared libraries anymore. This is a nightmare at different levels, and especially at security level.

We should probably interact more with the maintainers of the various BIOS package (that could mean synced release), in order to avoid this kind of problem. Of course it doesn't mean we should not provide the BIOS sources in QEMU.

Signature · 2 lines

Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net

Anthony Liguori

2010-03-05 13:52 UTC #7 lore raw

Quoted 54 lines · Aurelien Jarno

Quoted 46 lines · Anthony Liguori
Quoted 23 lines · Michael Tokarev
Hello.
There are a few bugs filed about an.. interesting behavour. For example:
   http://www.mail-archive.com/[email protected]/msg29834.html
   https://bugs.launchpad.net/qemu/+bug/513273
After quite some mix-n-matching, at least on my test machine, I can say that the issue gets triggered by seabios. When using pc-bios/bios.bin everything is ok. But when using any other bios.bin, even downloading seabios-0.5.1.tar.gz and building it - on a debian lenny system anyway - by running `make', the problem triggers.
I tried different versions/variations of vgabios.bin (it's only -vga std which triggers the issue so far), including 0.6b and 0.6c built from sources, vgabios.bin from debian packages (0.6b and 0.6c), and the one included in qemu-0.12.3.tar.gz. And my conclusion so far is that vgabios.bin has exactly _no_ effect on the issue.
Quoted 4 lines
But when using bios.bin from qemu-kvm-0.12.3.tar.gz, and _only_ that bios.bin, the problem goes away.
pc-bios/bios.bin gets built from roms/seabios.
We don't ship seabios 0.5.1 in 0.12.3, we ship 0.5.1-stable which is two commits ahead of 0.5.1.
Quoted 11 lines
So the question arises: where that pc-bios/bios.bin comes from into qemu-0.12.3.tar.gz? It is either built from some other sources (not from seabios-0.5.1), or built with some extra/different compiler/linker options, or built using different compiler/linker.
This is partially confirmed on ubuntu as well, but, as far as I understand, there the behavour is different with different versions of vgabios.
Quoted 6 lines
One of the reasons we include a git submodule and the source for the bios is so that distributors don't have to deal with building the packages independently. Morale of the story is, just use the source we ship and don't try to be more clever than that :-)

Quoted 7 lines

This is exactly what distribution usually fight about: same code in different packages, but with subtle differences. If every software was like that, we would not have shared libraries anymore. This is a nightmare at different levels, and especially at security level.
We should probably interact more with the maintainers of the various BIOS package (that could mean synced release),

We currently do this with SeaBIOS. But ultimately, x86 firmware is tied very closely to the underlying hardware.

Keep in mind, this is software that runs within a guest, not in the host environment. It's really more of a data file than anything else. It cannot be the source of a CVE.

Regards,

Anthony Liguori

Quoted 5 lines

in order to avoid this
kind of problem. Of course it doesn't mean we should not provide the BIOS sources in QEMU.