kernkonzept/fiasco

The development version of the L4Re Microkernel

fiasco's Issues

Support for Containers?

Hello, sorry if this isn't the right channel to ask, but I couldn't find one that looked more suitable.

Does Fiasco (or the non-kernel components that run on top of it) support containers?

If not, does Fiasco (or the non-kernel components that run on top of it) support concepts analogous to Linux namespaces and cgroups, to implement a container runtime on top of it?

Static Per_cpu objects constructed twice with !mp

Static Per_cpu<> objects are constructed twice in the same place if CONFIG_MP is disabled.

At least on x86, Per_cpu_data::run_ctors is called twice:

fiasco/src/kern/ia32/startup-ia32.cpp

Line 68 in b542159

Per_cpu_data::run_ctors(Cpu_number::boot_cpu());

fiasco/src/kern/kernel_thread.cpp

Line 76 in b542159

Per_cpu_data::run_ctors(Cpu::invalid());

Without CONFIG_MP, run_ctors does not make use of the Cpu_number argument:

fiasco/src/kern/per_cpu_data.cpp

Lines 170 to 182 in b542159

	IMPLEMENT inline
	void
	Per_cpu_data::run_ctors(Cpu_number)
	{
	extern ctor_function_t __PER_CPU_INIT_ARRAY_START__[];
	extern ctor_function_t __PER_CPU_INIT_ARRAY_END__[];
	run_ctor_functions(__PER_CPU_INIT_ARRAY_START__, __PER_CPU_INIT_ARRAY_END__);
	extern ctor_function_t __PER_CPU_CTORS_LIST__[];
	extern ctor_function_t __PER_CPU_CTORS_END__[];
	run_ctor_functions(__PER_CPU_CTORS_LIST__, __PER_CPU_CTORS_END__);
	}

Therefore, the Per_cpu<> objects are constructed twice in the same place when they should only be constructed once or twice but in different locations (as it happens with CONFIG_MP enabled).

This problem also seems to occur with Per_cpu_data::run_late_ctors and Per_cpu_data_alloc::alloc.
I discovered this issue by observing that Jdb_ipc_log_pm was constructed twice.

fiasco/src/jdb/ia32/jdb_trace_set-ia32-ux.cpp

Line 128 in b542159

DEFINE_PER_CPU static Per_cpu<Jdb_ipc_log_pm> _pm(Per_cpu_data::Cpu_num);

I have not verified that the issue still persists with the newest commit on master but there are no relevant code changes as far as I can see.

arm/fpu: eager FPU switching triggers assertion

After updating Fiasco.OC to the current state on Github (commit-id 4367c50), I've tested the new configuration option to always switch the FPU eagerly, because our user-level components make heavy use of the FPU anyway. But when the configuration option "Enable lazy FPU switching" is not set, the kernel runs into an assertion at the very beginning: src/kern/arm/32/fpu-arm.cpp:327. I have tested it on i.MX6 Quad Sabrelite.

ARM link error with binutils 2.36.1

When building Fiasco.OC for ARM with binutils 2.36.1 (as provided by Ubuntu 21.04), a link error occurs:

  ==> Linking fiasco.debug
arm-linux-gnueabihf-ld: cannot use executable file 'bootstrap.fiasco.o' as input to a link

The error is related to this binutils change: https://sourceware.org/bugzilla/show_bug.cgi?id=26047

x86/vmx: vmm can't cancel event (irq) injection

An attempt of a VMM to cancel a event (irq) injection is ignored at https://github.com/kernkonzept/fiasco/blob/master/src/kern/ia32/vm_vmx.cpp#L296. The upper bit of Vmx::F_entry_int_info may stay pending (valid) in the VMCS and an now unexpected virtual IRQ gets delivered to the VM as soon as interrupt delivery is enabled again in the VM. This leads in our case to a not booting VM because of invalid guest state VM exits during early boot. I encountered it during our work on a generalized x86 virtualization interface for Genode.

The commit alex-ab/foc@a841138 avoids the issue for us and let boot the VM successfully.

issues: kern/arm/gic.cpp

why returned?
it won't work,if i want to use Gic::set_mode.

352 Gic::set_mode(Mword pin, Mode m) override
353 {
354 return 0;

Maybe bug this line in bitmap.cpp ?

fiasco/src/lib/libk/bitmap.cpp

Line 141 in 146fc85

if (v & (1UL << bit))

Should be if (v & (1UL << b)) . Just like the function atomic_get_and_set above.

Possible array out of boundary for abs timeout in utcb

fiasco/src/abi/l4_types.cpp

Line 773 in 5eed420

Max_buffers = 58, ///< Number of BRs.

From code above shows Max_buffers is 58 . But the Line 972 shows we can get idx value up to 58.
So when idx==58, Line 974 u->buffers[idx] will out of array boundary. Is it a bug here?

fiasco/src/abi/l4_types.cpp

Line 795 in 5eed420

Mword buffers[Max_buffers];

fiasco/src/abi/l4_types.cpp

Line 972 in 5eed420

int idx = min<int>(_t & 0x3f, Utcb::Max_buffers);

fiasco/src/abi/l4_types.cpp

Line 974 in 5eed420

= reinterpret_cast<Utcb::Time_val const *>(&u->buffers[idx]);