| commit | 14e9e5d10dc39760b0dc60fd56d6c1e25af3b743 | [log] [tgz] |
|---|---|---|
| author | Alex Legg <alexlegg@google.com> | Sat Dec 08 15:37:10 2018 +1100 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Wed Dec 12 23:04:46 2018 +0000 |
| tree | 0d8c906b0f511014b815cb246a84100274c7702a | |
| parent | baa3fb322ac8623cdc78b6d65ea884209494af1b [diff] |
[x86][hypervisor] Clear tracked exceptions when injecting an interrupt Also, prioritise NMIs above other interrupts and exceptions. This was causing flakiness in the guest integration tests on release builds through the following order of events: 1. Linux guest begins a safe rdmsr 2. Hypervisor correctly responds by tracking a GP fault 3. On resume, a timer interrupt was prioritised before the exception 4. The guest exits again, then resumes injecting the GP fault 5. Guest panics because it receives an exception during the timer interrupt handler. This is likely also the cause for similar debian_guest failures in the past. There are two additional changes to follow: 1) Tidy up the use of X86_INT_PLATFORM_BASE to use X86_INT_MAX_INTEL_DEFINED instead, and handling undefined vectors. 2) Improved testing (See MAC-225). MAC-223 #done TEST=Run guest_integration_tests in a loop with a release build Change-Id: Ide64857f5442b023ac49c6369a2de8aaa305e2fe
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.