June 2019 - l4-hackers - example.com Site

Filesystem Architectures with L4Re and L4-Based Systems
by Paul Boddie 02 Dec '19

02 Dec '19

Hello, As this list can attest, I previously spent a bit of time diving into the way dynamic linking is supported by L4Re to get shared mode programs working. This turned out to have a relatively simple fix related to symbols employed by GCC- generated code. But during this exercise, I gained some familiarity with the way libraries are loaded, and this appears to involve the virtual filesystem support, with the loader perusing the filesystem to access libraries, and with these being provided as modules by the "rom" filesystem. Since then, I've spent some time looking at how files are provided by filesystems and accessed by code that uses the conventional C or POSIX library interfaces. It raises a few questions about why things are done in a particular way in L4Re, and which approaches are in use for other L4-based systems, especially those that seek to provide general-purpose, multi-user solutions. What I think I now understand about the virtual filesystem support in L4Re is as follows. The virtual filesystem itself is a "client-side" construct, meaning that it resides within any given program. That programs have their own view of a filesystem is not too different from what the documentation about systems like the Hurd describes and advocates, and I suppose it is a tempting approach because it gives each program the flexibility to be customised in this regard. However, it seems that beyond the internal "mount tree" representation, configuration of the namespace hierarchy is largely done using the L4Re namespace concept, with namespaces acting as directories, and non-namespace objects within the hierarchy interpreted as particular file types. Apart from the interpretation of namespaces as directories, it seems that for the most part, dataspaces are employed to be interpreted as file objects. I will admit that I didn't really look very hard at how different systems provide file access before now, but what surprised me slightly was the apparent lack of delegation in L4Re. As far as I can tell, on systems based on kernels like Linux, the open library function will employ a system call to delegate the matter of finding the file and obtaining a way of accessing it to the familiar monolithic-kernel-plus-filesystems arrangement. On more "exotic" systems (than Linux) like Minix 3 or the Hurd, it appears that delegation to a virtual filesystem server [1] or servers [2] occurs to mediate access to specific files. Some systems like Inferno and Plan 9 employ protocols [3] to formalise the client-server relationship. I had almost expected to find similar things in L4Re, but I could only confirm their absence after reviewing the various VFS abstractions. One thing I wonder about is whether the current L4Re approach is able to satisfactorily deal with filesystem content that needs to serve different user entities, with content having different permission and ownership rights. It seems that the filesystem logic has to be available as a library within a program, which is not necessarily a problem. But to avoid filesystem content being completely exposed to the discretion of user programs (reminiscent of the problems with early Network File System implementations), the library would need to call out to other entities, which doesn't appear to be done with the current L4Re abstractions. One could implement support for, say, the ext3 filesystem in a library, operating on a dataspace provided at some kind of mountpoint in a directory (with the directory being provided by a namespace, of course) but it would be like giving a user program access to a block device in a traditional Unix-like system. Are there any articles about the design of L4Re that might explain the motivations here? And are there any accessible-but-detailed articles about other microkernel-based systems and the way in which they structure their filesystem architectures? I looked around on the TU-Dresden site for materials, but I didn't immediately find anything obviously relevant. Paul [1] https://wiki.minix3.org/doku.php?id=developersguide:vfsinternals [2] https://www.gnu.org/software/hurd/hurd-talk.html#pat [3] http://doc.cat-v.org/inferno/4th_edition/styx

1 1

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

27 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 23 Jun '19

23 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 16 Jun '19

16 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 10 Jun '19

10 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