From bb756eebdac6fd24e8919e2c43f7d2c8c4091f59 Mon Sep 17 00:00:00 2001 From: RajithaY Date: Tue, 25 Apr 2017 03:31:15 -0700 Subject: Adding qemu as a submodule of KVMFORNFV This Patch includes the changes to add qemu as a submodule to kvmfornfv repo and make use of the updated latest qemu for the execution of all testcase Change-Id: I1280af507a857675c7f81d30c95255635667bdd7 Signed-off-by:RajithaY --- qemu/roms/seabios/docs/Execution_and_code_flow.md | 178 ---------------------- 1 file changed, 178 deletions(-) delete mode 100644 qemu/roms/seabios/docs/Execution_and_code_flow.md (limited to 'qemu/roms/seabios/docs/Execution_and_code_flow.md') diff --git a/qemu/roms/seabios/docs/Execution_and_code_flow.md b/qemu/roms/seabios/docs/Execution_and_code_flow.md deleted file mode 100644 index a54776eef..000000000 --- a/qemu/roms/seabios/docs/Execution_and_code_flow.md +++ /dev/null @@ -1,178 +0,0 @@ -This page provides a high-level description of some of the major code -phases that SeaBIOS transitions through and general information on -overall code flow. - -SeaBIOS code phases -=================== - -The SeaBIOS code goes through a few distinct code phases during its -execution lifecycle. Understanding these code phases can help when -reading and enhancing the code. - -POST phase ----------- - -The Power On Self Test (POST) phase is the initialization phase of the -BIOS. This phase is entered when SeaBIOS first starts execution. The -goal of the phase is to initialize internal state, initialize external -interfaces, detect and setup hardware, and to then start the boot -phase. - -On emulators, this phase starts when the CPU starts execution in 16bit -mode at 0xFFFF0000:FFF0. The emulators map the SeaBIOS binary to this -address, and SeaBIOS arranges for romlayout.S:reset_vector() to be -present there. This code calls romlayout.S:entry_post() which then -calls post.c:handle_post() in 32bit mode. - -On coreboot, the build arranges for romlayout.S:entry_elf() to be -called in 32bit mode. This then calls post.c:handle_post(). - -On CSM, the build arranges for romlayout.S:entry_csm() to be called -(in 16bit mode). This then calls csm.c:handle_csm() in 32bit mode. -Unlike on the emulators and coreboot, the SeaBIOS CSM POST phase is -orchastrated with UEFI and there are several calls back and forth -between SeaBIOS and UEFI via handle_csm() throughout the POST -process. - -The POST phase itself has several sub-phases. - -* The "preinit" sub-phase: code run prior to [code relocation](Linking overview#Code relocation). -* The "init" sub-phase: code to initialize internal variables and - interfaces. -* The "setup" sub-phase: code to setup hardware and drivers. -* The "prepboot" sub-phase: code to finalize interfaces and prepare - for the boot phase. - -At completion of the POST phase, SeaBIOS invokes an "int 0x19" -software interrupt in 16bit mode which begins the boot phase. - -Boot phase ----------- - -The goal of the boot phase is to load the first portion of the -operating system's boot loader into memory and start execution of that -boot loader. This phase starts when a software interrupt ("int 0x19" -or "int 0x18") is invoked. The code flow starts in 16bit mode in -romlayout.S:entry_19() or romlayout.S:entry_18() which then -transition to 32bit mode and call boot.c:handle_19() or -boot.c:handle_18(). - -The boot phase is technically also part of the "runtime" phase of -SeaBIOS. It is typically invoked immiediately after the POST phase, -but it can also be invoked by an operating system or be invoked -multiple times in an attempt to find a valid boot media. Although the -boot phase C code runs in 32bit mode it does not have write access to -the 0x0f0000-0x100000 memory region and can not call the various -malloc_X() calls. See [Memory Model](Memory Model) for -more information. - -Main runtime phase ------------------- - -The main runtime phase occurs after the boot phase starts the -operating system. Once in this phase, the SeaBIOS code may be invoked -by the operating system using various 16bit and 32bit calls. The goal -of this phase is to support these legacy calling interfaces and to -provide compatibility with BIOS standards. There are multiple entry -points for the BIOS - see the entry_XXX() assembler functions in -romlayout.S. - -Callers use most of these legacy entry points by setting up a -particular CPU register state, invoking the BIOS, and then inspecting -the returned CPU register state. To handle this, SeaBIOS will backup -the current register state into a "struct bregs" (see romlayout.S, -entryfuncs.S, and bregs.h) on call entry and then pass this struct to -the C code. The C code can then inspect the register state and modify -it. The assembler entry functions will then restore the (possibly -modified) register state from the "struct bregs" on return to the -caller. - -Resume and reboot ------------------ - -As noted above, on emulators SeaBIOS handles the 0xFFFF0000:FFF0 -machine startup execution vector. This vector is also called on -machine faults and on some machine "resume" events. It can also be -called (as 0xF0000:FFF0) by software as a request to reboot the -machine (on emulators, coreboot, and CSM). - -The SeaBIOS "resume and reboot" code handles these calls and attempts -to determine the desired action of the caller. Code flow starts in -16bit mode in romlayout.S:reset_vector() which calls -romlayout.S:entry_post() which calls romlayout.S:entry_resume() which -calls resume.c:handle_resume(). Depending on the request the -handle_resume() code may transition to 32bit mode. - -Technically this code is part of the "runtime" phase, so even though -parts of it run in 32bit mode it still has the same limitations of the -runtime phase. - -Threads -======= - -Internally SeaBIOS implements a simple cooperative multi-tasking -system. The system works by giving each "thread" its own stack, and -the system round-robins between these stacks whenever a thread issues -a yield() call. This "threading" system may be more appropriately -described as [coroutines](http://en.wikipedia.org/wiki/Coroutine). -These "threads" do not run on multiple CPUs and are not preempted, so -atomic memory accesses and complex locking is not required. - -The goal of these threads is to reduce overall boot time by -parallelizing hardware delays. (For example, by allowing the wait for -an ATA harddrive to spinup and respond to commands to occur in -parallel with the wait for a PS/2 keyboard to respond to a setup -command.) These hardware setup threads are only available during the -"setup" sub-phase of the [POST phase](#POST_phase). - -The code that implements threads is in stacks.c. - -Hardware interrupts -=================== - -The SeaBIOS C code always runs with hardware interrupts disabled. All -of the C code entry points (see romlayout.S) are careful to explicitly -disable hardware interrupts (via "cli"). Because running with -interrupts disabled increases interrupt latency, any C code that could -loop for a significant amount of time (more than about 1 ms) should -periodically call yield(). The yield() call will briefly enable -hardware interrupts to occur, then disable interrupts, and then resume -execution of the C code. - -There are two main reasons why SeaBIOS always runs C code with -interrupts disabled. The first reason is that external software may -override the default SeaBIOS handlers that are called on a hardware -interrupt event. Indeed, it is common for DOS based applications to do -this. These legacy third party interrupt handlers may have -undocumented expections (such as stack location and stack size) and -may attempt to call back into the various SeaBIOS software services. -Greater compatibility and more reproducible results can be achieved by -only permitting hardware interrupts at specific points (via yield() -calls). The second reason is that much of SeaBIOS runs in 32bit mode. -Attempting to handle interrupts in both 16bit mode and 32bit mode and -switching between modes to delegate those interrupts is an unneeded -complexity. Although disabling interrupts can increase interrupt -latency, this only impacts legacy systems where the small increase in -interrupt latency is unlikely to be noticeable. - -Extra 16bit stack -================= - -SeaBIOS implements 16bit real mode handlers for both hardware -interrupts and software request "interrupts". In a traditional BIOS, -these requests would use the caller's stack space. However, the -minimum amount of space the caller must provide has not been -standardized and very old DOS programs have been observed to allocate -very small amounts of stack space (100 bytes or less). - -By default, SeaBIOS now switches to its own stack on most 16bit real -mode entry points. This extra stack space is allocated in ["low -memory"](Memory Model). It ensures SeaBIOS uses a minimal amount of a -callers stack (typically no more than 16 bytes) for these legacy -calls. (More recently defined BIOS interfaces such as those that -support 16bit protected and 32bit protected mode calls standardize a -minimum stack size with adequete space, and SeaBIOS generally will not -use its extra stack in these cases.) - -The code to implement this stack "hopping" is in romlayout.S and in -stacks.c. -- cgit 1.2.3-korg