[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] bochs BIOS configuration and initialization
From: |
Rob Landley |
Subject: |
Re: [Qemu-devel] bochs BIOS configuration and initialization |
Date: |
Mon, 14 Oct 2013 02:52:46 -0500 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] bochs BIOS configuration and initialization,
Rob Landley <=