Hi,
The NOVA project is happy to announce that there is a prerelease of the
NOVA microhypervisor available for download at http://www.hypervisor.org/
or http://os.inf.tu-dresden.de/~us15/nova/ under the terms of the
GNU Public License version 2.
NOVA is based on a modern microhypervisor written in C++ and assembler.
It currently supports x86-32 SMP platforms with hardware virtualization
features, such as Intel VT-x or AMD-V, and facilitates running multiple
unmodified guest operating systems …
[View More]in virtual machines with near-native
performance. On machines without VT-x or AMD-V, the functionality is
reduced to that of a microkernel.
Like third-generation microkernels, the NOVA microhypervisor uses a
capability-based authorization model and provides only basic mechanisms for
spatial and temporal isolation, scheduling, communication and delegation of
platform resources. Additional services are provided by an unprivileged
multi-server user environment running on top of the microhypervisor.
In NOVA, we implemented almost all of the virtualization functionality in a
deprivileged user-level virtual-machine monitor. This design choice improves
the overall security of the system, because exploitation of a bug in the
platform virtualization code only compromises the VMM and leaves the
remaining components unaffected.
Cheers,
- Udo
[View Less]
Hi,
On 10-2-27 上午9:10, Dirk Vogt wrote:
> Hej,
> You're right. There is indeed a problem, which we haven't stumbled over
> yet. That is, because the irq handler runs at at a higher priority in
> our ddekit implementation. However on a multiprocessor machine this
I don't understand. How can using a higher priority in the irq handler
solve/avoid the problem? unless you mean running the softirq thread in a higher
priority. Otherwise, the softirq thread can still be preempted and …
[View More]lose raised
softirq as I mentioned in the previous letter.
> problem would indeed occur. We recognized the problem and are currently
> discussing solutions. One Solution would be to have one Soft-irq thread
> for each irq. You can expect a fix for this soon. If mach supports it
Isn't it the current implementation? In DDE, each driver has one irq and one
softirq thread?
> and you are using a single core machine a suggest to raise the prio of
> the irq handler thread in the ddekit as workaround.
In my current porting, I already raise the priority of the irq handler, but it
doesn't solve the problem.
I am thinking of using a lock to simulate cli/sti. When local_irq_enable() or
local_irq_save() is called, we hold the lock; when local_irq_restore() or
local_irq_disable(), we release the lock. We can even provide nested locking
support if local_irq_enable() or local_irq_save() is allowed to be called
multiple times in the same thread.
Best regards,
Zheng Da
[View Less]
Hello,
After I ported DDE Linux26 to the Hurd, I test it with a NIC driver: pcnet32,
and see a problem: device interrupt of the NIC device is sometimes masked but
cannot be unmasked.
Whenever pcnet32 driver receives an interrupt, it masks device interrupts and
calls __netif_rx_schedule() and let softirq to handle the interrupt.
__netif_rx_schedule() should set NET_RX_SOFTIRQ, but it can only do that when
the local "irq" is disabled (by calling local_irq_save macro). Linux disables
irq with …
[View More]cli instruction. Obviously DDE cannot do that, but the implementation
of local_irq_save in DDE is quite strange. It seems that it eventually calls
raw_local_irq_disable(), which is implemented in
linux26/lib/src/arch/l4/cli_sti.c. How can increasing _refcnt has anything to do
with disabling irq?
Without disabling irq, there is a race condition in the interrupt handler and
softirq handler. When I run pcnet32 with my ported DDE Linux26 for a long time,
I sometimes see softirq fails to be scheduled after the driver receives a hard IRQ.
I don't know how the Linux drivers can work with DDE Linux in L4.
raw_local_irq_disable() apparently has problems if I read the right code.
Best regards,
Zheng Da
[View Less]
The Genode project has released the new version 10.02 of the Genode
OS Framework. The framework is a modular user-level infrastructure
comprising device drivers, a GUI, networking support, a C library,
and Qt4. It can be executed directly on different microkernels, in
particular L4/Fiasco. Starting with the current release, we include
support for the recently released NOVA hypervisor into the official
Genode distribution. So there are now two kernels of the Dresden OS
group ready to use with …
[View More]the framework. For the technical details of
our porting effort, please refer to the release notes (see the link
below).
Moreover, we added support for the Codezero kernel and introduced a
new concept for managing real-time priorities on the L4ka::Pistachio
and OKL4 kernels. The most significant new functionality is the
initial port of the Python 2.6.4 script interpreter.
Release-notes summary for version 10.02
---------------------------------------
* Platform support
* NOVA hypervisor
* Codezero kernel
* New thread-context management
* Real-time priorities
* Python scripting
You can find the complete release notes for the version 10.02 here:
http://genode.org/documentation/release-notes/10.02/
The new release is available via the project's subversion repository
and at the Genode download page:
http://genode.org/download/latest-release
Regards
--
Norman Feske
Genode Labs
http://www.genode-labs.com · http://genode.org
[View Less]
Hello,
I recently had the problem that a physical memory area reserved for
Fiasco overlapped with a Bootloader area, resulting in one or possibly
more corrupted boot modules. Apparently there was not enough physical
memory available, but i would suggest that in this case Fiasco would
print an error message and stop as soon as it knows about the overlap
instead of further executing the corrupted modules.
Christian
[src] (17.00) jdb: kf
KIP @ 0xf0001000
magic: L4�K version: 0x87004444
…
[View More]clock: 0000000000623d7c (6438268)
freq_cpu: 2993136kHz
freq_bus: 0kHz
sigma0_ip: 00103de8 sigma0_sp: 002da720
sigma1_ip: 00000000 sigma1_sp: 00000000
root_ip: 010301dc root_sp: 00000000
Memory (max 30 descriptors):
1:phys [0000000000000000-000000000009fc00] Conventional
2:phys [0000000000100000-0000000003ff0000] Conventional
3:phys [0000000000001000-0000000000065000] Reserved
4:phys [000000000006a000-000000000006a400] Bootloader
5:phys [000000000009fc00-00000000000a0000] Arch
6:phys [00000000000e8000-0000000000100000] Arch
7:phys [0000000000100000-0000000000108400] Dedicated
8:phys [0000000001000000-0000000001065400] Bootloader
9:phys [00000000020de000-0000000003cef800] Bootloader
10:phys [0000000003ff0000-0000000004000000] Arch
11:phys [00000000fffc0000-0000000000000000] Arch
12:virt [0000000000000000-00000000c0000000] Conventional
13:phys [0000000003ad2000-0000000003ff0000] Reserved
KIP syscalls via absolute stubs
ipc: eacff000
id nearest: eacff100
fpage unmap: eacff200
thread switch: eacff300
thread schedule: eacff400
lthread ex regs: eacff500
task new: eacff600
user_ptr: 0x6a000 vhw_offset: 00000000 vkey_irq: 17
Kernel features: multi_irq exception_ipc segments pagerexregs deceit_bit_disables_switch abiver:9 io_prot utcb kip_syscalls thread_names
[View Less]