From patchwork Fri Mar 8 21:15:57 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Alex_Benn=C3=A9e?= X-Patchwork-Id: 160000 Delivered-To: patch@linaro.org Received: by 2002:a02:5cc1:0:0:0:0:0 with SMTP id w62csp9200030jad; Fri, 8 Mar 2019 13:16:31 -0800 (PST) X-Google-Smtp-Source: APXvYqxvlpMyjB2XcCsX5seCRIVqdfq13HsFohvmdbMZoq7aYe3Q1irxtwlahION3sKx3wg4FO21 X-Received: by 2002:a81:9bd0:: with SMTP id s199mr15769998ywg.446.1552079791784; Fri, 08 Mar 2019 13:16:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552079791; cv=none; d=google.com; s=arc-20160816; b=FODsTJpQBcayeh+8knNLnIUiEZbdT1sEnaSXtpIq6N930xWwIYBdv3YR6ZGCmVC5iS 7sP/kJnhP65RyFfQAJ8hFbTFQqPTOvr/x49hI4WPY5pJIHeaB9OZV35rBRdBbPNHSJXe 38hIt8WbLCtW4DhPqjzPruNPKJcO9MIiI4apcRGWjhc2ZJKwuuqRAqGNo82DrbJjQPlw fTG2BknQspcHz3Llo7ugg/TDRGjI0LlCiHw/TO9Jhjw0WZ3VnI5G6BdzHiGJFABhMZLI JHG3BOghc5z0mX3acoB/4EKIa+VbpFDajaE16C8OCz1twFUbXecilO8CNneold2RWmeX KaWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject :content-transfer-encoding:mime-version:message-id:date:to:from :dkim-signature; bh=vRwTFkSj5U1HQiWCOFW30NczurzWt4FLx+joGrfFJaQ=; b=nl3vRUzGCJBgdjg4tKjhE3XVqN4K/7/ED6ORatCCnzfgRZBsr5sFLMnl4imTHZwO9r jJpxZfhdS41vu4gMaJl5DMHUgu56/ENXzYE6M0yX7/zJvMIoEaVEqBdWg/O3CWygydCG bCjA/GenLHK0ui16W+DtPqOB8g6gStk58tr58t/z0BSD+zX+x18oyuFeT3E90gMcKZNv F5r9LR/InmRQpDUc4q4JhSO9mZfwcC/Z7gDNdp8wMhgpHxDFY3N0yDtMNkPOLlzf4Kaz UG0xY0bu95utQXAXjZ1uwaUX1kA7P0ZfQfSRBE7ScBSPb9elbYxRBkrSV5VKwlz9ohEy pn/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linaro.org header.s=google header.b=ThErtBaA; spf=pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+patch=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id q62si5758585ybc.112.2019.03.08.13.16.31 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 08 Mar 2019 13:16:31 -0800 (PST) Received-SPF: pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; dkim=fail header.i=@linaro.org header.s=google header.b=ThErtBaA; spf=pass (google.com: domain of qemu-devel-bounces+patch=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-devel-bounces+patch=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from localhost ([127.0.0.1]:50036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Mr1-0006jf-75 for patch@linaro.org; Fri, 08 Mar 2019 16:16:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Mqk-0006he-4l for qemu-devel@nongnu.org; Fri, 08 Mar 2019 16:16:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h2Mqh-0006Av-Ts for qemu-devel@nongnu.org; Fri, 08 Mar 2019 16:16:13 -0500 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]:34916) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h2Mqg-00067N-Oe for qemu-devel@nongnu.org; Fri, 08 Mar 2019 16:16:11 -0500 Received: by mail-ed1-x544.google.com with SMTP id g19so17513867edp.2 for ; Fri, 08 Mar 2019 13:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vRwTFkSj5U1HQiWCOFW30NczurzWt4FLx+joGrfFJaQ=; b=ThErtBaAq0Dj1y3xzDDdBt5on9jeAQeypIercyx0ick5bAV3nS0kgJgOkM8G62sKO/ ILLtlpOtTC0MTGunxCveVxJC0IWczr3eQFoiPd3+dQXPjgJ5QePoX3nMHa0WIV8m0nik 9pV0Ar01mb1gJpRFoeFzcPrWdeCUaRw4nIRQkbUsNV4Azmf9Tg7oWaeoekxJoR3jWEiy d36oRnak1v4YFhpAczT4LxlQRmzvqwQI7glcqZ9BQ5tT/bpbVgFJzrP+RtEPo6AHiIsI P9D9vQQQ3LCY/bOZ5v5ZMLRTphFP8PPwoqU8YVOoW/BorlhWUK1czs4HXvM1EOUlPwT2 gmtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vRwTFkSj5U1HQiWCOFW30NczurzWt4FLx+joGrfFJaQ=; b=e7vXRpuT0jnY0PIszI5DQgyfNIB7o37W/1Oaky1iIFhYax2s1v9cwML4XE/V3Lh3dB cOuj5lSFP/tsRUmXhUpVuFXxgN+mwO/TFOEHhJHFIM/UTFk3MErjYQ2T82z3QljpWqhX N+FpesM0iRDC1iuyc/yPyrbFBcbw1xonNcYXfQJKJCVDVjfTUY8GkBQF4lAl3M/BLtxz 4+lb9mvgaNEO3F2vYlbZFS1dO01qtHQSxzzeA9ScjcUGMgZwUz7WfRFFdAjXD1+Z3lwi qHqGdFzU4UtS6iVLGyZ1VVcjIaj4Fjb2ye7FI55+ToucjKPlL+Qm+4OZIKDIgcTbiMnN Cyxg== X-Gm-Message-State: APjAAAV0HBcvYkKf444Ff4r2pwhJ49lcR+tDIT7jl1nBV6ffOb7hBgH0 teCFoFdUwptrNn7sVWBdRGRDVA== X-Received: by 2002:a17:906:970a:: with SMTP id k10mr13307958ejx.102.1552079766810; Fri, 08 Mar 2019 13:16:06 -0800 (PST) Received: from zen.linaroharston ([81.128.185.34]) by smtp.gmail.com with ESMTPSA id w33sm2576367edd.62.2019.03.08.13.16.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Mar 2019 13:16:06 -0800 (PST) Received: from zen.linaroharston. (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id C225A1FF82; Fri, 8 Mar 2019 21:16:05 +0000 (UTC) From: =?utf-8?q?Alex_Benn=C3=A9e?= To: qemu-devel@nongnu.org Date: Fri, 8 Mar 2019 21:15:57 +0000 Message-Id: <20190308211557.22589-1-alex.bennee@linaro.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::544 Subject: [Qemu-devel] [RFC PATCH] docs/booting.rst: start documenting the boot process X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, thuth@redhat.com, ehabkost@redhat.com, borntraeger@de.ibm.com, mst@redhat.com, mark.cave-ayland@ilande.co.uk, f4bug@amsat.org, armbru@redhat.com, shannon.zhaosl@gmail.com, agraf@suse.de, hpoussin@reactos.org, pbonzini@redhat.com, rth@twiddle.net, =?utf-8?q?Alex_Benn=C3=A9e?= , david@gibson.dropbear.id.au Errors-To: qemu-devel-bounces+patch=linaro.org@nongnu.org Sender: "Qemu-devel" While working on some test cases I realised there was quite a lot of assumed knowledge about how things boot up. I thought it would be worth gathering this together in a user facing document where we could pour in the details and background to the boot process. As it's quite wordy I thought it should be a separate document to the manual (which can obviously reference this). So far I've managed almost a thousand words and haven't actually related anything to QEMU's options yet. So going forward: - is this a useful document to have in docs? - are there any other areas to mention? - out auto-magic -bios selection seems like something worth covering - should we have some worked examples of command lines? - I was thinking for example of read-only and pflash examples - we should also describe why direct kernel boots exits - and also the fact they are not that direct (some code executes before a kernel - even if it's less than a full firmware) Submitted for comment.... Signed-off-by: Alex Bennée --- docs/booting.rst | 127 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 docs/booting.rst -- 2.20.1 diff --git a/docs/booting.rst b/docs/booting.rst new file mode 100644 index 0000000000..a8a644ff9a --- /dev/null +++ b/docs/booting.rst @@ -0,0 +1,127 @@ +===================================== +Anatomy of a Boot, a QEMU perspective +===================================== + +This document attempts to give an overview of how machines boot-up and +how this matters to QEMU. We will discuss firmware and BIOSes and the +things they do before the OS kernel is loaded and your usable system +is finally ready. + +Firmware +======== + +When a CPU is powered up it knows nothing about it's environment. It's +internal state, including the program counter (PC), will be reset to a +defined set of values and it will attempt to fetch it's first +instruction and execute it. It is the job of the firmware to bring a +CPU up from it's first few instructions to running in a relatively +sane execution environment. Firmware tends to be specific to the +hardware in question and is stored on non-volatile memory (memory that +survives a power off) usually a ROM or flash device on the computers +main board. + +Some examples of what firmware does include: + +Early Hardware Setup +-------------------- + +Modern hardware often requires configuring before it is usable. For +example most modern systems won't have working RAM until the memory +controller has been programmed with the correct timings for whatever +memory is installed on the system. Processors may boot with a very +restricted view of the memory map until RAM and other key peripherals +have been configured to appear in it's address space. Some hardware +may not even appear until some sort of blob has been loaded into it so +it can start responding to the CPU. + +Fortunately for QEMU we don't have to worry too much about this very +low level configuration. The device model we present to the CPU at +start-up will generally respond to IO access from processor straight +away. + +BIOS or Firmware Services +------------------------- + +In the early days of the PC era the BIOS or Basic Input/Output System +provided an abstraction interface to the operating system which +allowed them to do basic IO operations without having to directly +drive the hardware. Since then the scope of these firmware services +have grown as systems become more and more complex. + +Modern firmware often follows the Unified Extensible Firmware +Interface (UEFI) which provides services like secure boot, persistent +variables and external time-keeping. + +There can often be multiple levels of firmware service functions. For +example systems which support secure execution enclaves generally have +a firmware component that executes in this secure mode which the +operating system can call in a defined secure manner to undertake +security sensitive tasks on it's behalf. + +Hardware Enumeration +-------------------- + +It's easy to assume that modern hardware is built to be discover-able +and all the operating system needs to do is enumerate the various +buses on the system to find out what hardware exists. While buses like +PCI and USB do support discovery there is usually much more on a +modern system than just these two things. + +In the embedded world it used to be acceptable to have a custom +compiled kernel which knew where everything is meant to be. However +this was a brittle approach and not very flexible - most obviously if +you try and use a kernel compiled for one piece of hardware on another +piece of hardware that might nominally have the same processor. + +The more modern approach is to have a "generic" kernel that has a +number of different drivers compiled in which are then enabled based +on a hardware description provided by the firmware. This allows +flexibility on both sides. The software distribution is less concerned +about managing lots of different kernels for different pieces of +hardware. The hardware manufacturer is also able to make small changes +to the board over time to fix bugs or change minor components. + +The two main methods for this are the Advanced Configuration and Power +Interface (ACPI) and Device Trees. ACPI originated from the PC world +although is becoming increasingly common for "enterprise" hardware +like servers. Device Trees of various forms have existed for a while +with perhaps the most common being Flattened Device Trees (FDT). + +Boot Code +========= + +The line between firmware and boot code is a very blurry one. However +from a functionality point of view we have moved from ensuring the +hardware is usable as a computing device to finding and loading a +kernel which is then going to take over control of the system. Modern +firmware often has the ability to boot a kernel directly and in some +systems you might chain through several boot loaders before the final +kernel takes control. + +The boot loader needs to do 3 things: + + - find a kernel and load it into RAM + - ensure the CPU is in the correct mode for the kernel to boot + - pass any information the kernel may need to boot and can't find itself + +Once it has done these things it can jump to the kernel and let it get +on with things. + +Kernel +====== + +The Kernel now takes over and will be in charge of the system from now +on. It will enumerate all the devices on the system (again) and load +drivers that can control them. It will then locate some sort of +file-system and eventually start running programs that actually do +work. + +------------------------ +How this relates to QEMU +------------------------ + +TODO: + + - -bios and -drive flash + - dynamic and fixed hardware definitions + - direct kernel boots