mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-31 19:17:04 +00:00
9d67f9fc8e
This patch removes old 'Allocator_guard' utility and replaces its use with the modern 'Constrained_ram_allocator'. The adjustment of core in this respect has the side effect of a more accurate capability accounting in core's CPU, TRACE, and RM services. In particular, the dataspace capabilities needed for core-internal allocations via the 'Sliced_heap' are accounted to the client now. The same goes for nitpicker and nic_dump as other former users of the allocator guard. Hence, the patch also touches code at the client and server sides related to these services. The only remaining user of the 'Allocator_guard' is the Intel GPU driver. As the adaptation of this component would be too invasive without testing, this patch leaves this component unchanged by keeping a copy of the 'allocator_guard.h' locally at the component. Fixes #3750 |
||
|---|---|---|
| .. | ||
| frontend | ||
| generic | ||
| include | ||
| nova | ||
| patches | ||
| spec/nova | ||
| audio.cc | ||
| devices.cc | ||
| devxhci.cc | ||
| drivers.cc | ||
| dummies.cc | ||
| dynlib.cc | ||
| hm.cc | ||
| libc.cc | ||
| logger.cc | ||
| mm.cc | ||
| mm.h | ||
| network.cpp | ||
| pdm.cc | ||
| pgm.cc | ||
| README | ||
| rt.cc | ||
| sup.h | ||
| svm.h | ||
| target.inc | ||
| target.mk | ||
| thread.cc | ||
| unimpl.cc | ||
| util.h | ||
| vcpu_svm.h | ||
| vcpu_vmx.h | ||
| vcpu.h | ||
| vmm.h | ||
| vmx.h | ||
VirtualBox configuration options ################################ The configuration requires an attribute named vbox_file with the name of the vbox configuration to be used (.vbox). <config vbox_file="file.vbox"> XHCI controller =============== The virtual XHCI controller can be enabled with the following configuration option: <config xhci="yes"> CAPSLOCK ======== <config capslock="ROM"> If the capslock attribute is set to "ROM", virtualbox will open a connection to the ROM named "capslock" and expect in the top-level node a attribute 'enabled' (yes|no). If the ROM capslock differ from the internal VM capslock, the VMM will trigger aritifical capslock key events to the VM.