|
NOVA User-Level Environment
Version testbox/changed-memory-timing-317-g320d8b5
|
|
NOVA User-Level Environment
Version testbox/changed-memory-timing-317-g320d8b5
|
Sigma0 is the root task (i.e. it runs in a root protection domain and it is the first task run by the hypervisor). Its initialization is controlled by command line parameters. Every parameter basically describe the operations to be performed on startup. In Sigma0 sources, every parameter is defined with PARAM_HANDLER() macro. Its first argument is the name of the parameter, the second argument is the code to be performed when the parameter is encountered in the script and the rest of arguments are lines of the help text.
After all parameters are processed, the main thread blocks and Sigma0 is controlled only through inter-process communication (IPC).
The entry point of sigma0 is the symbol start, which is defined to be the same as static method Sigma0::start() in sigma0.cc. This function is called from program.h, which defines __start symbol (an entry point defined in the linker script).
Sigma0 class inherits _free_virt members, which is a region list used to manage free virtual memory for later delegation to children. Initially, all memory is put into this list.
Memory mapping is only possible during IPC. Therefore, to map the memory from hypervisor sigma0 calls itself through "echo portal". This is implemented in map_self() method. The actual mapping is performed by hypervisor during reply to the echo call. It cannot be done during the call, because utcb->crd of receiving thread must correspond the mapping and the caller cannot easily manipulate utcb->crd of the receiving thread.
Memory allocations (operator new) is implemented in library called service (file simplemalloc.cc). The implementation simply calls the function pointed out by memalloc pointer, whose value defaults to memalloc_mempool().
Sigma0 uses a more sofisticated memory allocator defined in sigma0_memalloc(). It allocates physical memory by consulting _free_phys region list and then maps the memory to its address space.
Memory freeing (memfree pointer) is not currently implemented.
At some places, NUL uses an uncommon new syntax, e.g.:
new (0x1000) char[0x1000]
The parameters in parentheses after new are passed as additional parameters to the overloaded operator new. In case of NUL, the additional parameter specifies the alignment of the memory block.
Portal wrapper functions cannot be greped - they are defined with PT_FUNC() or PT_FUNC_NORETURN() macros.
TODO How are capability selectors allocated?
| Capability indices | Use |
|---|---|
| 0 – 0x10000 | reserved by program.h |
| 0xff | parent id - parent identifies us by translation of this capability to its PD |
| 0x100 – 0x1ff | MAC_CPUS??? - new parent protocol. |
| 0x200 | semaphore to block the main thread after initialization is done |
| 0x10000 – 0xffffffff | (CLIENT_PT_OFFSET, CLIENT_PT_ORDER) |
The following is the excerpt from a boot log on a 2-CPU system sorted by the capability selector (idx*). Note that these events are not normally logged; these messages were only added for the purpose of this list. It lists the objects created in sigma0, their selectors and other parameters. Memory mapping selectors are not included in this list.
The communication is currently handled by means of "devices" interconnected via various "buses". Sigma0 is also a "device". Currently, all the devices live in a single address space and therefore the bus simply pass the messages (sent by calling send_*() method) to receiving devices by calling receive() method of all devices on the bus.
Technically, the receive() methods are called by static methods inherited from StaticReceiver class template. This template generates static methods receive_static() which simply call normal member functions receive(). There might be several of these functions differentiated by the type of the message.
The diagram below tries to express interconnection between the devices (ellipses) and the buses (rectangles). It was created semi-automatically so there might be some inaccuracies. The connections of bus_hostop and bus_hwioin/out were intentionally not included because almost every devices sends the messages there. dot
TimerService is a service that provides timers and time functionality to its clients. It currently runs within Sigma0, but it is planned to run in its own protection domain.
It listens on portal to perform requests from clients. The main services provided are OPEN, REQUEST_TIMER, REQUEST_TIME and CLONE. OPEN operation creates a semaphore which is shared with the client. This semaphore is signaled when a timer, set up with REQUEST_TIMER, fires.
TimerService internally uses motherboard and buses _mymb), similarly as Sigma0, but these seem not to be used for anything useful.
dot
This driver handles keyboard (and probably even mouse) IRQs, translates the scancodes somehow and sends MessageInput messages to bus_input.
The HostKeyboard 0 is special in that it allows switching consoles and reboot host and guest systems. The HostKeyboard 0 is initialized by the following SIgma0 parameter:
hostkeyb:0,0x60,1
I do not yet fully understand how console works, but it seems it might be like this:
The actual virtual consoles are implemented in HostVga. A virtual console is a set of views and the view seems to be basically a bunch of VGA and VGA memory. The emulations seems to provide both text and graphical modes. HostVga worker thread periodically (25Hz) updates the real VGA with the content of the currently selected view.
TODO How is console attached to other protection domains? What is exactly bus_console used to.
Listens for MessageInput and uses this for switching the consoles.
Starting of programs other than Sigma0 (let us call them children) is controlled by configuration scripts (text files with .nulconfig extension). The scripts have to be loaded by the bootloader into the memory. Programs can be started either automatically by using script and script_start:<num>:1 Sigma0 parameters or manually by keyboard shortcuts (by default LWin+<num>). The number <num> refers to the num-th .nulconfig script.
The actual spawning of the program is implemented in Sigma0::_start_config(). It involves the following steps:
The portal capability selectors are allocated in the range base – base + 0x400. The base is calculated as CLIENT_PT_OFFSET + (<num>-1)*(1<<CLIENT_PT_SHIFT), i.e. for the first client the range is equal to 0x10000 - 0x10400.
During the protection domain creation the capabilities in the range described above (base through base + 0x10400) are delegated to the client where they occupy selectors from 0x0 to 0x400. Therefore, the child knows implicitely how to contact the parent and how to idetify itself to the parent (see parent protocol).
| Selector | Symbol | Capability |
|---|---|---|
| 0x00E | Page fault handling portal (handled in Sigma0) | |
| 0x01E | Startup exception handling portal (handled in Sigma0) | |
| 0x020 | NOVA_DEFAULT_PD_CAP | Child protection domain |
| 0x0FF | ParentProtocol::nil | Identifier (a semaphore) the parent uses to distinguish between clients |
| 0x100, 0x101, ... | ParentProtocol::nil | Per-CPU portals for calling the parent using a [[parent protocol]]. |
sigma0::cpu specifies the CPU where to create the new program.sigma0::dma TODOTODO
1.8.1.2