Re: [Qemu-devel] bochs BIOS configuration and initialization

[Rob Landley]

On 09/30/2013 12:25:45 PM, Min LI wrote:
> Dear all,
>
>       I am very interested in QEMU and trying to figure out the boot  
> process of guest VM. According to my understanding about QEMU code,  
> bochs BIOS is loaded into memory by pc_system_firmware_init(…).  
> However, I notice QEMU handles hardware initialization, allocates  
> memory and stores user's configuration in fw_cfg. In addition, QEMU  
> loads linux by load_linux(…). Then my question is what does bochs  
> BIOS do during the  period guest VM boots. Based on my understanding,  
> QEMU has already finished many works belong to BIOS, why does QEMU  
> load BIOS into memory?
>
>         I will really appreciate any comments and help.

The bochs BIOS loads the boot sector from emulated hard drives,  
provides the BIOS callbacks from Ralph Brown's interrupt list so the  
boot sector can load the rest of the bootloader and print messages on  
the screen during boot, plus some low level hardware probing like  
"where is the physical memory".

Early boot code (BIOS, u-boot, etc) do several things:

1) Initialize hardware (most prominently the DRAM controller that does  
memory refresh).

2) Provide a minimal bootloader to load other code into memory and run  
ig.

3) Provide callbacks so that early code can access primitive I/O  
drivers without having to contain its own.

4) Provide hardware description data (from device tree all that  
horrible ACPI nonsense).

Classic 16-bit PC bios did DRAM init, loaded the boot sector, and  
provided the "bios calls" so the boot sector could load more sectors  
and write text to the screen. (Ralph brown's interrupt list documented  
those bios calls.) Some of those bios calls returned data about how  
many disks you could load stuff from and how much memory was in the  
system (later this was replaced by data tables describing address  
ranges where physical memory was present, and still later by ACPI  
because the Intel guys didn't want itanic to depend on running 8086  
code so they shoehorned a half-assed Java interpreter into ROM).

Anyway, all of these BIOS functions got cloned as open source, but it  
took two projects:

1) Coreboot (formerly linuxbios) handles the early hardware init,  
primarily DRAM init. Until the DRAM controller is initialized and  
refreshing the DRAM, it won't remember what was stored in it so you  
have to run out of non-volatile memory (or at least non-DRAM,  
processors tend to have a little SRAM built in to act as cache.  
Coreboot cleverly maps the L2 cache to act as the early C stack, for  
example, since it doesn't need to be refreshed. Pin a TLB entry, tell  
it never to write back to underlying DRAM until it's evicted, zero it  
out, and then carefully don't touch any other memory until you finish  
DRAM init...)

QEMU doesn't need coreboot, because it doesn't emulate the hardware at  
that level.

2) Bochs bios. Takes over once the system is up enough to run stuff out  
of DRAM. QEMU uses that to load boot sector and provide bios callbacks  
for basic I/O services to write to the screen and load more sectors  
from boot device and such.

Projects like u-boot combine both functions into one giant hairball.

Rob