[Qemu-devel] pc-bios/bios.bin - where it comes from?

[Qemu-devel] pc-bios/bios.bin - where it comes from?

[Michael Tokarev]

Hello.

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

 http://www.mail-archive.com/kvm@vger.kernel.org/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

[Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Anthony Liguori]

On 03/04/2010 04:46 PM, Michael Tokarev wrote:
> Hello.
>
> There are a few bugs filed about an.. interesting
> behavour.  For example:
>
>   http://www.mail-archive.com/kvm@vger.kernel.org/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.
>    

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.

> 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 :-)

> 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



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

[Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Michael Tokarev]

Anthony Liguori wrote:
> On 03/04/2010 04:46 PM, Michael Tokarev wrote:
>> Hello.
>>
>> There are a few bugs filed about an.. interesting
>> behavour.  For example:
>>
>>   http://www.mail-archive.com/kvm@vger.kernel.org/msg29834.html
>>   https://bugs.launchpad.net/qemu/+bug/513273
>>
[]
> 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.
[]
> 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 :-)
> 
>> 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.

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.

>> 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

[Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Anthony Liguori]

On 03/05/2010 03:17 AM, Michael Tokarev wrote:
> 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.

>    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

[Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Michael Tokarev]

Anthony Liguori wrote:
> On 03/05/2010 03:17 AM, Michael Tokarev wrote:
>> 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..

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

Thanks!

/mjt

[Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Gerd Hoffmann]

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

   Hi,

>> 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.

> 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


[-- Attachment #2: vgabios-pci.patch --]
[-- Type: text/plain, Size: 4528 bytes --]

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.

diff --git a/clext.c b/clext.c
index c7a2ad0..b0b6834 100644
--- a/clext.c
+++ b/clext.c
@@ -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
diff --git a/vbe.c b/vbe.c
index 87f7414..8af5255 100644
--- a/vbe.c
+++ b/vbe.c
@@ -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
diff --git a/vgabios.c b/vgabios.c
index 3fd9f2f..1738b47 100644
--- a/vgabios.c
+++ b/vgabios.c
@@ -3830,6 +3830,64 @@ void printf(s)
 }
 #endif
 
+ASM_START
+  ; get LFB address from PCI
+  ; in - ax: PCI device vendor
+  ; out - ax: LFB address (high 16 bit)
+  ;; NOTE - may be called in protected mode
+_pci_get_lfb_addr:
+  push bx
+  push cx
+  push dx
+  push eax
+    mov bx, ax
+    xor cx, cx
+    mov dl, #0x00
+    call pci_read_reg
+    cmp ax, #0xffff
+    jz pci_get_lfb_addr_5
+ pci_get_lfb_addr_3:
+    mov dl, #0x00
+    call pci_read_reg
+    cmp ax, bx ;; check vendor
+    jz pci_get_lfb_addr_4
+    add cx, #0x8
+    cmp cx, #0x200 ;; search bus #0 and #1
+    jb pci_get_lfb_addr_3
+ pci_get_lfb_addr_5:
+    xor dx, dx ;; no LFB
+    jmp pci_get_lfb_addr_6
+ pci_get_lfb_addr_4:
+    mov dl, #0x10 ;; I/O space #0
+    call pci_read_reg
+    test ax, #0xfff1
+    jnz pci_get_lfb_addr_5
+    shr eax, #16
+    mov dx, ax ;; LFB address
+ pci_get_lfb_addr_6:
+  pop eax
+  mov ax, dx
+  pop dx
+  pop cx
+  pop bx
+  ret
+
+  ; read PCI register
+  ; in - cx: device/function
+  ; in - dl: register
+  ; out - eax: value
+pci_read_reg:
+  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
+ASM_END
+
 #ifdef VBE
 #include "vbe.c"
 #endif
-- 
1.6.6.1

Re: [Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Aurelien Jarno]

Anthony Liguori a écrit :
> On 03/04/2010 04:46 PM, Michael Tokarev wrote:
>> Hello.
>>
>> There are a few bugs filed about an.. interesting
>> behavour.  For example:
>>
>>   http://www.mail-archive.com/kvm@vger.kernel.org/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.
>>    
> 
> 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.
> 
>> 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 :-)
> 

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.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] Re: pc-bios/bios.bin - where it comes from?

[Anthony Liguori]

On 03/05/2010 07:39 AM, Aurelien Jarno wrote:
> Anthony Liguori a écrit :
>    
>> On 03/04/2010 04:46 PM, Michael Tokarev wrote:
>>      
>>> Hello.
>>>
>>> There are a few bugs filed about an.. interesting
>>> behavour.  For example:
>>>
>>>    http://www.mail-archive.com/kvm@vger.kernel.org/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.
>>>
>>>        
>> 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.
>>
>>      
>>> 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 :-)
>>
>>      
> 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


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