l4-hackers

l4-hackers@os.inf.tu-dresden.de

2827 discussions

Fiasco.OC-UX on MIPS?
by Paul Boddie 30 Sep '19

30 Sep '19

Hello again, Having been using the MIPS-based CI20 single-board computer a bit more recently, I wondered if it might be possible to get the user mode Fiasco kernel working on MIPS. As I understand it, the UX variant of Fiasco only works on IA32 (x86, 32-bit), and although MIPS isn't particularly popular, it would at least be useful to me. However, having looked at the code, it seems like quite a bit of work to unpick the IA32-related aspects from the UX-specific code. There appears to be a fair amount of descriptor table usage, for instance, and despite reading the thesis about it [1], I don't feel I have a decent-enough overview of what would really need doing to port the UX variant to another architecture. So far, I've reviewed the MIPS code which employs a Proc abstraction and has a number of functions in the Mips namespace which could be replaced to maintain a "virtual" processor in the user mode kernel. It seems that the existing UX variant employs an Emulation abstraction for things like the processor status, and perhaps the Proc abstraction could take over these responsibilities. Quite how many privileged CPU registers would need maintaining probably depends on how much other code would still be using them. This brings me to an awkward difference between IA32 and MIPS: that of the page fault handling and memory management. MIPS has no inherent notion of page table structures that are held by the CPU and consulted by it when addressing errors occur. Instead, an exception handler is invoked to populate various privileged registers and to perform privileged instructions. However, it seems to me that Fiasco needs to maintain a page directory, anyway, and that the user mode kernel is not likely to be attempting the actual memory management operations, either. Consequently, it is tempting to think that the existing UX code might also be usable on MIPS. This would actually involve replacing a dedicated page directory implementation that appears to be present for MIPS with the one that other architectures appear to use. One detail that might need preserving is the code path dealing with TLB lookups (as a consequence of addressing errors), but it may be the case that page faults are dealt with more directly when signals arrive - perhaps what the UX code does now - and that the TLB exception vectors will remain unused. When considering some of these issues, I did wonder about the role of certain architecture-specific aspects of the MIPS implementation. The existing UX code seems to deal with "vectors" and seems rather connected to interrupt descriptor tables (or their emulation). On MIPS, exception vectors are typically resident in kernel memory and have specific addresses. It seems to me that the handling of exceptions (caused by signals) would direct execution via these vectors and thus preserve the existing exception.S implementation, albeit relocated to user memory. I guess the alternative would involve rewriting such things and using emulated processor features directly instead of trapping and handling privileged instructions. (I did also wonder to what extent the assembly language could also be migrated to C++ even for the native MIPS implementation.) That brings me to a discussion about the purpose of the user mode kernel variant. As I understand it, one of the aims is to preserve architecture- specific code so as to give that code some possible testing and general exercise: it might actually help in the development of the kernel more generally. Is this a reasonable understanding? Initially, I thought that UX would actually be architecture-neutral (in terms of mechanisms; obviously the code would be native), but it appears that a stated aim is to be able to run existing binaries unchanged. Would an architecture-neutral UX variant make any sense? I suppose I could go on and on, here, but as far as I can tell there are quite a few things that would need deciding in order to have a realistic chance of ever getting this working, amongst others that I will have forgotten or not considered... * Redefining the memory layout for kernel and task processes (so as to work within the host system constraints) * Separating generic and native functionality for various central abstractions * Replacing the memory management with a mechanism similar to that employed by the existing UX code * Defining a usable interrupt and exception paradigm (here, I am tempted to introduce a second-level controller for user mode interrupts) * Determining which modules are required and how the code should be built (largely using the existing UX configurations) * Testing and integrating the host system functionality required for the user mode kernel to function (process tracing, signal handling, system call invocations using the trampoline, thread management) On this last point, I investigated the trampoline mechanism on a MIPS Linux system, and it does seem viable. There are a few tricks to getting system calls working (that can be learned from glibc and the kernel itself), although the trick employed to cancel them may not work. Also, the paper [1] describes the need to acquire signal context information by deploying a signal handler and having processes capture context data on the kernel's behalf. This may not be necessary on MIPS since the interesting details - those that seem to be posted on the stack when IA32 exceptions occur - are available via the registers exposed by ptrace on MIPS. Indeed, I learned that ptrace is something of a fickle friend, not necessarily providing the same level of support on all systems. And thus, I wondered if there is still much sustained interest in the user mode approach or if people regard other technologies to be more practical and/or interesting. If you have read this far, maybe you might be able to share your thoughts on the topic. It has been frustrating trying to get a good overview of the code - I'm not sure the preprocessor really helps, to be honest - and while I would like to be able to get the user mode kernel working on another architecture, I would rather like to know if it is really worth my while. Getting a better understanding is therefore the first step in finding out. Paul [1] http://os.inf.tu-dresden.de/papers_ps/steinberg-beleg.pdf

4 11

Unable to create Goos FB in UEFI mode
by Adi Lima 09 Sep '19

09 Sep '19

Hi, I've been trying to make this one work, but in vain, so far... Either using qemu or in real hardware, all failed when booting from UEFI. >From qemu's stdio I know that the boot has been completed successfuly, but it seems like fb-drv was unable to support current default mode from EFI Framebuffer boot (or it is trying to switch to some other mode, and failed?). I was using standard ex_fb_spectrum_cc, with x86-fb.io, x86-fb.cfg and x86-legacy.devs, all loaded by grub2 as Multiboot2 and Module2 Everything was fine if booted using BIOS, but I haven't try on UEFI mode with CSM. Can you give me a hint of what to try next, please? Thanks in advance :-) -- FX. J. Adi Lima Trivision Studio

2 1

Full virtualization on Raspberry PI 4
by clim atisefr 29 Aug '19

29 Aug '19

Hi, I know the Raspberry PI 3 does not support the full virtualization and only para-virtualization is supported. It seems that the Raspberry PI 4 with the Broadcom 2711 (Quad-core Cortex-A72 ARM v8 64-bit SoC @ 1.5 GHz) may support it. Is there any development to support this platform with L4RE ? or any hint to start it ? Thanks, Chris

2 1

Porting Pistachio to Cell
by Tyson Key 22 Aug '19

22 Aug '19

Hi, In a wave of projects, over the years, I've been working on trying to rescue the Pistachio GitHub repository from bitrot, and build it with modern tools (I have one project that builds, and runs on x86, with an ancient version of GRUB, and another, that's a complete basket case, since KickStart is broken, but that's another matter), and saw, with some interest, ports to various Open Firmware-enabled platforms, and wondered if anyone had any guides to building, and running a PowerPC 64-bit userland, and boot infrastructure? There was an old guide to building with PSIM, and PPC32, on the KIT Website, but it seems incomplete, and it doesn't seem obvious, as to how one would build a bootable disk image, or how to prepare the compiled userland to run on hardware. Since the site is pretty dated, and the code has changed, since then, is that information even relevant? I've got access to a FreeBSD 12 PPC64 build environment, under QEMU's PSeries Xenial machine emulator, and I'm in the process of trying to set up a direct development environment, on a PlayStation 3 system, so access to PowerPC toolchains isn't a problem. Eventually, I'm planning on seeing if I can use the existing code, and parts of FreeBSD's PlayStation 3 port, to implement a basic, first-draft port to run on Sony's CellOS/BEAT ABI-based hypervisor, or in GameOS mode, with PetitBoot. Thanks in advance, for any assistance, Tyson Key.

1 0

New L4Re component released: virtio-net
by Jakub Jermar 29 Jul '19

29 Jul '19

Dear L4 hackers, last week we released virtio-net on GitHub[0]. Together with the previously released L4Re components, virtio-net can be used to interconnect two VMs with a virtual network. We also wrote a little tutorial which illustrates that[1]. Happy hacking, Jakub [0] https://github.com/kernkonzept/virtio-net [1] https://github.com/kernkonzept/manifest/wiki/MultipleVMs -- Kernkonzept GmbH at Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael Hohmuth

1 0

kernel error
by ssrmurthy saka 04 Jul '19

04 Jul '19

Hi team, I am using "4.13.0-36-generic" kernel and i exported cross compiler of version "gcc-linaro-7.4.1-2019.02-i686_arm-linux-gnueabihf". when i try to compile new odule i am facing below error. can you please help on this. make -C /lib/modules/4.13.0-36-generic/build/ M=/home/tessolve/c modules make[1]: Entering directory '/usr/src/linux-headers-4.13.0-36-generic' CC [M] /home/tessolve/c/vm.o In file included from ./include/asm-generic/int-ll64.h:10:0, from ./arch/arm/include/uapi/asm/types.h:4, from ./include/uapi/linux/types.h:4, from ./include/linux/compiler.h:231, from ./include/linux/init.h:4, from /home/tessolve/c/vm.c:1: ./include/uapi/asm-generic/int-ll64.h:11:10: fatal error: asm/bitsperlong.h: No such file or directory #include <asm/bitsperlong.h> ^~~~~~~~~~~~~~~~~~~ compilation terminated. scripts/Makefile.build:315: recipe for target '/home/tessolve/c/vm.o' failed make[2]: *** [/home/tessolve/c/vm.o] Error 1 Makefile:1550: recipe for target '_module_/home/tessolve/c' failed make[1]: *** [_module_/home/tessolve/c] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-36-generic' Makefile:4: recipe for target 'all' failed make: *** [all] Error 2 Thanks, murthy

1 0

Want to run L4Re on Raspberry PI.
by Lei Zhou 28 Jun '19

28 Jun '19

HI, I'm looking for the information and procedure how to compile and deploy L4Re on Raspberry PI. Any feedbacks would be greatly appreciated! Thanks, Lei

5 26

Enable L4Linux network access on Raspberry Pi-b.
by Lei Zhou 24 Jun '19

24 Jun '19

Hi Adam & Hackers, Has anybody enabled network access for L4linux Raspberry pi3? I read through all the history on related topics and understand the process to get it working. I summarized the steps as below and major problem for me is how to convert device tree for L4linux and compose corresponding rpi_deices.io configuration. Please see my specific question inlined in those steps. Thanks in advance for your feedback. 1. configure and Compile l4linux to support flattened device tree support. Also enables CONFIG_USB_LAN78XX=y && CONFIG_USB_USBNET=y CONFIG_USB_NET_SMSC95XX=y CONFIG_L4_SERVER = y CONFIG_USE_OF = y 2. Adapt https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2… into ./l4linux/arch/l4/boot/dts/simple.dts [Lei's question]: I understand why bcm2710-rpi-3-b.dts cannot be used directly because some of the reg_address physical address doesn't apply and might fail to be mapped. How can I pick network access specific device nodes and its dependancies(power or clock etc) and how to change those illegal reg_address? 3. Create an rpi3_devices.io for L4Re with the devices and their resources and assign the desired devices to a vbus. [Lei's question]: Should I define all device nodes one-2-one mapping from step 2's device tree? 4. Update your ned script and modules.list -- vim:set ft=lua: local L4 = require("L4"); loader = L4.default_loader; -- Start io vbus_l4linux = loader:new_channel(); --vbus_input = loader:new_channel(); --vbus_fbdrv = loader:new_channel(); loader:start( { caps = { sigma0 = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0); icu = L4.Env.icu; -- input = vbus_input:svr(); l4linux = vbus_l4linux:svr(); -- fbdrv = vbus_fbdrv:svr(); }, log = {"IO", "y"}, l4re_dbg = L4.Dbg.Warn, }, "rom/io -vvv rom/rpi_devices.io"); -- Start L4linux loader:start( { caps = { -- fb = mag_svc:create(L4.Proto.Goos, "g=640x480"); vbus = vbus_l4linux; }, log = L4.Env.log:m("rws"), l4re_dbg = L4.Dbg.Warn, }, "rom/vmlinuz mem=64M console=ttyLv0 l4x_rd=rom/ramdisk- l4x_dtb=rom/rpi3b-simple.dtb" .. L4.Info.arch() .. ".rd " .. "root=1:0 ramdisk_size=4000 init=/bin/sh earlyprintk=1 "); 5. Build final bootstrap_l4linux.uimage for Raspberry. Thanks very much! Lei Zhou

2 2

How to enable Guest Linux VM on Raspberry PI3?
by Lei Zhou 17 Jun '19

17 Jun '19

After I brought up L4Re and Fiasco on Raspberry PI3, would like to enable guest Linux VM on top of it. I'm looking at the link https://github.com/kernkonzept/manifest/wiki/LinuxVM and hoping I can do the same thing on Raspberry PI3. The link seems using hardware-assisted virtualization option uvmm based for guest VM. There seems also L4Linux Paravirtualization option. Which option should I use for me to enable guest LInux VM on Raspberry PI3? In addition, when I followed the link to try on QEMU first, encounter some "vbus" capability issue. I followed the guidance exactly as the link says. However, when I started the command to spawning the Linux VM as: $make E=uvmm-basic qemu It failed with following log: ============================================ MOE: virtual user address space [0-7fffffffff] MOE: rom name space cap -> [C:103000] MOE: rwfs name space cap -> [C:105000] BOOTFS: [41100000-411974b8] [C:107000] uvmm BOOTFS: [41198000-411c4e58] [C:109000] l4re BOOTFS: [411c5000-41246770] [C:10b000] ned BOOTFS: [41247000-412475c4] [C:10d000] virt-arm_virt.dtb BOOTFS: [41248000-41430200] [C:10f000] ramdisk-armv8.cpio.gz BOOTFS: [41431000-41431242] [C:111000] uvmm-basic.ned BOOTFS: [41432000-42618a00] [C:113000] Image.gz MOE: cmdline: moe rom/uvmm-basic.ned MOE: Starting: rom/ned rom/uvmm-basic.ned MOE: loading 'rom/ned' Ned says: Hi World! Ned: loading file: 'rom/uvmm-basic.ned' VMM[vmbus]: 'vbus' capability not found. Hardware access not possible for VM. VMM[main]: Hello out there. VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus VMM[vm]: Device creation for virtual device virtio_uart@20000 failed. Disabling device. VMM[]: virtio_net(a)10000.l4vmm,virtiocap: capability net is invalid. VMM[vm]: Device creation for virtual device virtio_net@10000 failed. Disabling device. VMM: FATAL: ERROR: ARM GIC virtualization does not work without passing the virtual GICC via the vbus VMM[vm]: Device creation for virtual device interrupt-controller failed. Disabling device. VMM: FATAL: Parsing timer interrupt: Argument out of range qemu-system-aarch64: terminating on signal 2 Makefile:6: recipe for target 'do-all-make-goals' failed make: *** [do-all-make-goals] Interrupt ========================================================================= Any feedbacks are greatly appreciated! Lei Zhou

3 9

L4Re, BUILD_ARCH, cross-building for ARM on MIPS
by Paul Boddie 11 Jun '19

11 Jun '19

Hello, In attempting to investigate building L4Re/Fiasco.OC for the Raspberry Pi Zero, I encountered an unusual problem: unusual because, I suppose, most people do not try and cross-build on architectures other than x86(-64). When performing the initial L4Re build directory initialisation step... make B=mybuild ...BUILD_ARCH seems to be set to x86 even on other architectures. This then causes CCXX_FLAGS to be populated with x86-dependent settings such as -m32, and the gcc host compilers for MIPS raise errors upon encountering these unrecognised arguments. Here is the offending command in the top-level Makefile (line 376 in my version, r83 in Subversion): GENDEP_OUTPUT=$$X.out $(CC) $(CCXX_FLAGS) -c $$X -o $$X.o Although it seemed like the config step could be performed after ignoring these errors, I did wonder if there might be some undesirable consequences. In the end, I found that the following invocation was needed: make B=mybuild CC=gcc CXX=g++ LD=ld BUILD_ARCH=mips CPU=32r2 CPU_ABI=32 After that, things seem to work as expected. I imagine that there is a "chicken and egg" situation here: the appropriate settings would be obtained from the configuration, but the command being run sets up the configuration. Has anyone else seen this problem before? Paul

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
283
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers