* Re: [Qemu-devel] bochs BIOS configuration and initialization
2013-09-30 17:25 [Qemu-devel] bochs BIOS configuration and initialization Min LI
@ 2013-10-14 7:52 ` Rob Landley
0 siblings, 0 replies; 2+ messages in thread
From: Rob Landley @ 2013-10-14 7:52 UTC (permalink / raw)
To: Min LI; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 2+ messages in thread