From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVcxY-000222-27 for qemu-devel@nongnu.org; Mon, 14 Oct 2013 03:53:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVcxO-000862-7E for qemu-devel@nongnu.org; Mon, 14 Oct 2013 03:53:00 -0400 Received: from mail-oa0-f52.google.com ([209.85.219.52]:42122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVcxO-00085r-2C for qemu-devel@nongnu.org; Mon, 14 Oct 2013 03:52:50 -0400 Received: by mail-oa0-f52.google.com with SMTP id n2so4157785oag.25 for ; Mon, 14 Oct 2013 00:52:48 -0700 (PDT) Date: Mon, 14 Oct 2013 02:52:46 -0500 From: Rob Landley In-Reply-To: (from sdytlmqemu@gmail.com on Mon Sep 30 12:25:45 2013) Message-Id: <1381737166.1974.195@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] bochs BIOS configuration and initialization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Min LI Cc: qemu-devel@nongnu.org On 09/30/2013 12:25:45 PM, Min LI wrote: > Dear all, >=20 > I am very interested in QEMU and trying to figure out the boot =20 > process of guest VM. According to my understanding about QEMU code, =20 > bochs BIOS is loaded into memory by pc_system_firmware_init(=E2=80=A6). =20 > However, I notice QEMU handles hardware initialization, allocates =20 > memory and stores user's configuration in fw_cfg. In addition, QEMU =20 > loads linux by load_linux(=E2=80=A6). Then my question is what does bochs= =20 > BIOS do during the period guest VM boots. Based on my understanding, =20 > QEMU has already finished many works belong to BIOS, why does QEMU =20 > load BIOS into memory? >=20 > I will really appreciate any comments and help. The bochs BIOS loads the boot sector from emulated hard drives, =20 provides the BIOS callbacks from Ralph Brown's interrupt list so the =20 boot sector can load the rest of the bootloader and print messages on =20 the screen during boot, plus some low level hardware probing like =20 "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 =20 memory refresh). 2) Provide a minimal bootloader to load other code into memory and run =20 ig. 3) Provide callbacks so that early code can access primitive I/O =20 drivers without having to contain its own. 4) Provide hardware description data (from device tree all that =20 horrible ACPI nonsense). Classic 16-bit PC bios did DRAM init, loaded the boot sector, and =20 provided the "bios calls" so the boot sector could load more sectors =20 and write text to the screen. (Ralph brown's interrupt list documented =20 those bios calls.) Some of those bios calls returned data about how =20 many disks you could load stuff from and how much memory was in the =20 system (later this was replaced by data tables describing address =20 ranges where physical memory was present, and still later by ACPI =20 because the Intel guys didn't want itanic to depend on running 8086 =20 code so they shoehorned a half-assed Java interpreter into ROM). Anyway, all of these BIOS functions got cloned as open source, but it =20 took two projects: 1) Coreboot (formerly linuxbios) handles the early hardware init, =20 primarily DRAM init. Until the DRAM controller is initialized and =20 refreshing the DRAM, it won't remember what was stored in it so you =20 have to run out of non-volatile memory (or at least non-DRAM, =20 processors tend to have a little SRAM built in to act as cache. =20 Coreboot cleverly maps the L2 cache to act as the early C stack, for =20 example, since it doesn't need to be refreshed. Pin a TLB entry, tell =20 it never to write back to underlying DRAM until it's evicted, zero it =20 out, and then carefully don't touch any other memory until you finish =20 DRAM init...) QEMU doesn't need coreboot, because it doesn't emulate the hardware at =20 that level. 2) Bochs bios. Takes over once the system is up enough to run stuff out =20 of DRAM. QEMU uses that to load boot sector and provide bios callbacks =20 for basic I/O services to write to the screen and load more sectors =20 from boot device and such. Projects like u-boot combine both functions into one giant hairball. Rob=