September 2025 - Devel - lists.sel4.systems

seL4 vs QNX and Linux benchmarks
by Andrew Warkentin 07 Oct '25

07 Oct '25

Somebody in the Zoom call the other day (IIRC it was Gernot) said that seL4 IPC is considerably faster than QNX IPC, but it seems that QNX is somehow faster in a simple benchmarking experiment in which a client repeatedly sends messages to a bit-bucket server, using the TSC to determine timing. I'm running both QNX and seL4 under identical VirtualBox configurations with a single core. I'm using a QNX 6.3.1 x86-32 image i have in my collection (x86-64 support was only added in 7.0; this is the most recent image I have with dev tools installed). The seL4 version I'm using is from February 2022 and is built for x86-64 with MCS enabled (the priority of the threads is 255, and both the timeslice and budget are the initial thread default of 5 ms). My benchmark times a loop of 10000 RPCs; for QNX it's just using the regular read() function on /dev/null or a custom server that also acts like /dev/null but forces a copy of the message into a server-provided buffer, and for seL4 I'm directly calling Send()/Recv()/Reply(). I've also tested Linux's /dev/null, and QNX's implementation actually seems somewhat faster than it (for the system /dev/null; the custom server's best case seems only slightly worse than under Linux). Under QNX and Linux I'm running a C implementation of the benchmark and under seL4 I tried both C and Rust implementations (which have very similar performance). The messages on QNX and Linux are 100 bytes, and on seL4 they are 2 words, which should be hitting the fast path. Here are the best and worst cases I got: seL4: 0.114-0.136s QNX, custom null server: 0.006-0.063s QNX, system null server: 0.002-0.022s Linux: 0.004-0.005s Has anyone else benchmarked seL4 IPC against that of QNX and gotten better (or comparable) results for seL4, unlike what I got? Is synchronous IPC just less optimized under seL4 than QNX?

6 13

seL4 developer hangout reminder
by Birgit Brecknell 29 Sep '25

29 Sep '25

Hi all A friendly reminder that the seL4 developer hangout is on again this week. Tue 30 Sep, 22:00 UTC For your local date and time please see https://sel4.systems/stay-informed.html#calendar Zoom link: https://unsw.zoom.us/j/82640784431 Birgit Brecknell seL4 Foundation Project Coordinator Sydney, Australia Mon 9-5 Wed 2-5 Fri 9-5 birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

Systems Researcher Position
by Yanyan Shen 23 Sep '25

23 Sep '25

Hi seL4 developers NIO uses seL4 as the kernel for the vehicle operating system, and we are seeking a systems software researcher / developer to join the team. Please see the job description. [https://nio.wd3.myworkdayjobs.com/NIO_Careers/job/San-Jose-US/Systems-Softw…] If you enjoy building systems from scratch, writing high quality system code, optimizing performance, turning your research ideas into awesome real-world products, and shaping the future of systems software for intelligent EVs, the position is for you. Please drop me an email if you would like to know more. Looking forward to hearing from you. Regards, Yanyan [Banner]<http://www.nio.io> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. You may NOT use, disclose, copy or disseminate this information. If you have received this email in error, please notify the sender and destroy all copies of the original message and all attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

1 0

seL4 developer hangout reminder
by Birgit Brecknell 15 Sep '25

15 Sep '25

Hi all A friendly reminder that the seL4 developer hangout is on again this week. Wed 17 Sep, 8:00 UTC For your local date and time please see https://sel4.systems/stay-informed.html#calendar Zoom link: https://unsw.zoom.us/j/82640784431 Birgit Brecknell seL4 Foundation Project Coordinator Sydney, Australia Mon 9-5 Wed 2-5 Fri 9-5 birgit(a)sel4.systems <mailto:birgit@sel4.systems> bbrcknl(a)gmail.com <mailto:bbrcknl@gmail.com>

1 0

Kernel use of MPIDR_EL1 register on ARM
by Julia Vassiliki 09 Sep '25

09 Sep '25

For ARM platforms, the hardware provides access to the MPIDR ("Multiprocessor Identification Register") [1], which, amongst other things, provides access to 2 (or 3, for AArch64) affinity levels: Aff0, Aff1, Aff2, and possibly Aff3. However, seL4 instead seems to gather the CPU index from a loader-set `tpidr_el1`. /* tpidr_el1 has the logic ID of the core, starting from 0 */ mrs x6, tpidr_el1 /* Set the sp for each core assuming linear indices */ ldr x5, =BIT(CONFIG_KERNEL_STACK_BITS) mul x5, x5, x6 This is then overwritten later. with the kernel stack address. Is there any reasoning for why it was done this way? The elfloader [3] then has read the MPIDR and converted it to TPIDR_EL1 for the kernel, and it uses a generated table to map the MPIDR IDs to "logical core IDs" [4]. Here is the boot log for the TX2, which does use non-contiguous Aff0 IDs. Boot cpu id = 0x100, index=2 Core 257 is up with logic id 1 Core 258 is up with logic id 2 Core 259 is up with logic id 3 Enabling MMU and paging Of note here is 2 things: 1. That the ARM PSCI specification [5], for "target_cpu" when calling PSCI_ON or OFF methods (such as done in the elfloader) expects a MPIDR-like ID (I say "like" because it is with the "U" and "MT" bits masked out). In its current state, the seL4_BootInfo provided ID is instead the logical ID, which means that there's no way to see the value of MPIDR from userspace. 2. The GICv3 uses MPIDR affinity values when sending IPIs, and so the kernel does actually maintain a "mpidr_map" which wouldn't be necessary if everything talked in terms of MPIDRs. (It would still be required for other reasons on SMP as opposed to multikernel, though). BOOT_CODE void cpu_initLocalIRQController(void) { word_t mpidr = 0; SYSTEM_READ_WORD(MPIDR, mpidr); mpidr_map[CURRENT_CPU_INDEX()] = mpidr; active_irq[CURRENT_CPU_INDEX()] = IRQ_NONE; gicr_init(); cpu_iface_init(); } In the spirit of being a minimal hardware abstraction, I feel that it makes more sense for the kernel's APIs to be in terms of MPIDRs [6], but that it would probably be a breaking change. Internally, aside from this, it makes *more* sense for the kernel to think in terms of MPIDRs for the core values, rather than a "logical core ID". Some context for how this is represented in the device trees: In the device tree documentation 'Documentation/devicetree/bindings/arm/cpus.yaml' [2] the `<reg>` field of the cpus node tells the values of each of the CPU nodes; mapping the affinities (possibly non-contiguous) to a contiguous CPU index could be done with a build-time lookup table. For example, here is the first part of the OdroidC4 device tree, which tells us that node 0 is Aff0=0, Aff1=0. cpus { #address-cells = <0x02>; #size-cells = <0x00>; cpu@0 { device_type = "cpu"; reg = <0x00 0x00>; }; /* etc */ } [1]: https://arm.jonpalmisc.com/latest_sysreg/AArch64-mpidr_el1 [2] https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/cpus.yaml [3]: https://github.com/seL4/seL4_tools/blob/26f94df7e97a04f8ee49c1e94a0aa120365… [4]: https://github.com/seL4/seL4_tools/blob/master/elfloader-tool/src/arch-arm/… [5]: https://documentation-service.arm.com/static/6703a8b8d7e4b739d817e10d [6]: So, the SMP affinity APIs, and BootInfo->nodeID field. Julia This email and any files transmitted with it may contain confidential information. If you believe you have received this email or any of its contents in error, please notify me immediately by return email and destroy this email. Do not use, disseminate, forward, print or copy any contents of an email received in error.

3 3

About MSI-X interrupts on x86
by Alberto Lange 05 Sep '25

05 Sep '25

Hi all, here Albert I’m working on a SuperMicro E300-9D server and trying to passthrough an Intel X557-AT2 NIC to a Linux 6.1 guest. The .camkes configuration seems to be right, here are the configs for the device (the device is correctly detected on the VM): vm2.vm_ioports = []; vm2.pci_devices = [ { "name":"outer_eth", "bus":0xb5, "dev":0x0, "fun":1, "irq":"outer_eth", "memory":[ {"paddr":0xf9000000, "size":0x01000000, "page_bits":12}, // BAR0 {"paddr":0xfb000000, "size":0x00008000, "page_bits":12}, // BAR3 ] } ]; vm2.vm_irqs = [ {"name":"outer_eth", "ioapic":0, "source":0xb, "level_trig":0, "active_low":1, "dest":12} ]; I’m seeing the following errors during boot and when bringing the interface up: [ 2.040786] i40e 0000:00:01.0: MAC address: 3c:ec:ef:d2:88:85 [ 2.090786] i40e 0000:00:01.0: MSI-X vector reservation failed: -38 [ 2.109960] i40e 0000:00:01.0: MSI-X not available, trying MSI [ 2.115660] i40e 0000:00:01.0: MSI init failed - -38 [ 2.121656] i40e 0000:00:01.0: MSI-X and MSI not available, falling back to Legacy IRQ [ 2.220802] i40e 0000:00:01.0 eth1: NIC Link is Up, 1000 Mbps Full Duplex, Flow Control: None [ 2.290774] i40e 0000:00:01.0: Features: PF-id[1] VSIs: 66 QP: 1 VxLAN Geneve PTP VEPA ... # ifconfig eth1 up [ 451.042525] i40e 0000:00:01.0 eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 5770 ms [ 451.052764] i40e 0000:00:01.0 eth1: tx_timeout: VSI_seid: 391, Q 0, NTC: 0x0, HWB: 0x1, NTU: 0x1, TAIL: 0x1, INT: 0x0 [ 451.065876] i40e 0000:00:01.0 eth1: tx_timeout recovery level 2, txqueue 0 [ 456.082601] i40e 0000:00:01.0 eth1: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 10810 ms My thought is that this NIC does not work reliably with legacy IRQ mode. My question is: Is there any implementation of MSI-X interrupts for x86 in the seL4 VMM, or plans to support it? If such support exists, I would like to contribute, as I plan to share my project once it’s finished. Thanks in advance for any guidance or suggestions. Albert

3 4