FreeBSD Status Report - First Quarter 2026

Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Lorenzo Salvadore <salvadore_at_freebsd.org>
Date: Thu, 23 Apr 2026 14:53:29 UTC

FreeBSD Status Report First Quarter 2026

Here is the first 2026 status report, with 45 entries.

This is the first status report since we changed the schedule and started
enforcing it. As you can see, we are indeed on schedule! It is being published
within one month of the end of the quarter, as expected!

It has a very high number of entries (for reference, 2025Q4 had 28) in spite of
the fact that we waited much less.

Have a nice read!

Lorenzo Salvadore, on behalf of Status Team

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A rendered version of this report is available here:
https://www.freebsd.org/status/report-2026-01-2026-03/

Table of Contents

• FreeBSD Team Reports
□ FreeBSD Foundation
□ FreeBSD Release Engineering Team
□ Ports Collection
□ Cluster Administration Team
□ Bugmeister Team
• Projects
□ Cyber Resilience Act (CRA) Readiness Project
□ More robust pkgbase conversion
□ Alpha-Omega Beach Cleaning project
□ FreeBSD Software Bill of Materials
□ Laptop Testing and Integration Project
□ Desktop Script for BSDInstall
□ A bhyve management GUI written in Freepascal/Lazarus
□ Full CPUID Control for bhyve
□ Sylve — A Unified System Management Platform for FreeBSD
□ AppJail, AppScripts and Sandboxed X11 Applications
□ daemonless: Native FreeBSD OCI Containers
□ Kernel Benchmark, MAINTAINERS, and pkgdist
□ LLDB Improvement on FreeBSD
• Userland
□ Process Descriptor API completion
• Kernel
□ ACPI Driver for System76 Laptops
□ Suspend/Resume Improvements
□ Hibernate (aka Suspend-to-disk)
□ Collaborative Processor Performance Control (CPPC)
□ Audio Stack Improvements
□ LinuxKPI 802.11 and Native Wireless Update
□ Removal of RFC 2675 Support
□ GENEVE Tunnel
• Architectures
□ drm-kmod: Build and run on ARM64 with 16.0-CURRENT
□ FreeBSD Driver Development for BananaPi-R64/R2-PRO
□ NXP DPAA2 support
□ amd64 FRED support
□ Support for the Allwinner H616 SOC Family
• Cloud
□ FreeBSD on EC2
□ STACKIT Cloud Integration on FreeBSD
□ Containers and FreeBSD: Cloud Native Buildpacks
• Documentation
□ The FreeBSD Russian Documentation Project
• Ports
□ KDE on FreeBSD
□ GCC on FreeBSD
□ Valgrind: stabilization, FreeBSD 16 fixes and additions
□ Improve OpenJDK on FreeBSD
□ Make openjdk21 the default JAVA_VERSION
□ Make openjdk25 the default JAVA_VERSION
□ Wazuh on FreeBSD
□ FreeBSD HPC Modernization Initiative: Ecosystem Expansion and Upstream
Integration
□ Improve libvirt support for bhyve hypervisor

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the
Administration Page.

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://freebsdfoundation.org/
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://freebsdfoundation.org/donate/
Foundation Partnership Program URL:
https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://freebsdfoundation.org/journal/
Foundation Events URL: https://freebsdfoundation.org/our-work/events/

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

The FreeBSD Foundation is a 501(c)(3) non-profit dedicated to advancing FreeBSD
through both technical and non-technical support. Funded entirely by donations,
the Foundation supports software development, infrastructure, security, and
collaboration efforts; organizes events and developer summits; provides
educational resources; and represents the FreeBSD Project in legal matters.

OS Improvements

In the first quarter of 2026, there were 555 src, 83 ports, and 16 doc commits
sponsored by the FreeBSD Foundation.

Refer to these report entries describing much of that sponsored development
work:

• Alpha-Omega Beach Cleaning Project

• amd64 FRED support

• Audio Stack Improvements

• Desktop Script for BSDInstall

• FreeBSD Software Bill of Materials

• Full CPUID Control for bhyve

• Hibernate (aka Suspend-to-disk)

• Improve libvirt Support for bhyve Hypervisor

• Improve OpenJDK on FreeBSD

• Kernel Benchmark, MAINTAINERS, and pkgdist

• Laptop Testing and Integration Project

• LinuxKPI 802.11 and Native Wireless Update

• LLDB Improvement on FreeBSD

• More robust pkgbase conversion

• Process Descriptor API completion

• Removal of RFC 2675 Support

• Support for the Allwinner H616 SOC Family

• Suspend/Resume Improvements

• Sylve — A Unified System Management Platform for FreeBSD

Other highlights:

• The Foundation is supporting two projects: the Laptop Support and Usability
project (in collaboration with Quantum Leap Research), and a Cyber
Resilience Act Readiness Project.

• For background on the Laptop Support and Usability project, refer to the
2025Q1 quarterly status report.

• FreeBSD has been accepted to participate in Google Summer of Code (GSoC)
2026. Potential contributors have submitted their applications to Google,
and we will learn how many FreeBSD projects will be funded on April 30.

Advocacy

In the first quarter of 2026, our advocacy work focused on expanding our
educational video content, reaching more viewers than ever, bringing the
community together for a productive Vendor Summit, and reflecting on the work
that is helping sustain and grow interest in FreeBSD. Here are just a few of
the ways the Foundation advocated for FreeBSD in Q1 2026:

• Helped represent FreeBSD at FOSDEM 2026, SCALE 23X, AsiaBSDCon, and CHERI
Blossoms Conference

• Began planning the June 2026 FreeBSD Developer Summit, taking place June
17-18, 2026, co-located with BSDCan 2026; Registration is now open

• Finalized our Silver Sponsorship of BSDCan and opened the BSDCan 2026
Travel Grant Application

• Signed for a Silver level sponsorship to AsiaBSDCon26, which took place
March 19-22, 2026, in Taipei, Taiwan.

• Deb Goodkin, Executive Director of the FreeBSD Foundation, will be speaking
at Open Source Summit North America, hosted by the Linux Foundation on May
19, 2026

• Published the following blogs and videos to help to inform and educate the
community:

□ Getting ready for the Cyber Resilience Act

□ Build a NAS using FreeBSD on a Raspberry Pi (video)

□ Getting Started with FreeBSD: A resource guide for beginners

• Published the January 2026, February 2026, and March 2026 FreeBSD
Foundation Newsletters

• Released the October/November/December issue of the FreeBSD Journal with
HTML versions of the articles

Continuous Integration and Workflow Improvement

The Foundation supports a full-time staff member dedicated to improving the
Project’s continuous integration system and test infrastructure.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them. We also provide legal support for the core team to investigate
questions that arise.

Go to https://freebsdfoundation.org to find more about how we support FreeBSD
and how we can help you!

FreeBSD Release Engineering Team

Links:
FreeBSD 14.4-RELEASE announcement URL:
https://www.freebsd.org/releases/14.4R/announce/
FreeBSD 15.1-RELEASE schedule URL:
https://www.freebsd.org/releases/15.1R/schedule/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL:
https://download.freebsd.org/snapshots/ISO-IMAGES/

Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>

The FreeBSD Release Engineering Team is responsible for setting and publishing
release schedules for official project releases of FreeBSD, announcing code
freezes and maintaining the respective branches, among other things.

The Team managed 14.4-RELEASE, leading to the official RELEASE build and
announcement in March. Planning has started for the upcoming 15.1-RELEASE,
which is due to arrive in June.

The Team gained four new members, Sergio Carlavilla Delgado, Craig Leres,
Vladlen Popolitov, and Alexander Ziaee, and two members have departed: Jake
Freeland and Mahdi Mokhtari. We thank them for their contributions.

The Release Engineering Team continued providing weekly development snapshot
builds for the main, stable/15, stable/14, and stable/13 branches. Note that
the weekly snapshot builds for stable/13 will end when that branch reaches its
End-of-Life at the end of April.

Ports Collection

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL:
https://docs.freebsd.org/en/articles/contributing/#ports-contributing
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>

The Ports Management Team is responsible for overseeing the overall direction
of the Ports Tree, building packages, and personnel matters. Below is what
happened in the last quarter.

During the last quarter, we welcomed Yusuf Yaman (nxjoseph), Kousuke Kannagi
(mce), Piotr Smyrak (smyru), Laurent Chardon (laurent), and Kenneth Raplee
(kenrap) as new ports committers, and said goodbye to one committer.

According to INDEX, there are currently 37,958 (up from 37,163) ports in the
Ports Collection. There are currently about 2,710 (down from 3,428) open ports
PRs, of which 798 (down from 821) are unassigned. The last quarter saw 8,970
(up from 8,738) commits by 166 (up from 156) committers on the main branch and
697 (down from 898) commits by 59 (down from 61) committers on the 2026Q1
branch.

The most active committers to main were:

• 2135 sunpoet@FreeBSD.org

• 800 yuri@FreeBSD.org

• 528 vvd@FreeBSD.org

• 312 bofh@FreeBSD.org

• 294 tagattie@FreeBSD.org

• 182 nivit@FreeBSD.org

• 177 arrowd@FreeBSD.org

• 175 eduardo@FreeBSD.org

• 153 fuz@FreeBSD.org

• 132 mfechner@FreeBSD.org

A lot has happened in the ports tree in the last three months, an excerpt of
the major software upgrades are:

• pkg 2.6.2

• New USES: inotify

• Default version of Go switched to 1.25

• Default version of Java switched to 21 (and 11 on armv*)

• Default version of Lazarus switched to 4.6 (and 4.99 on aarch64 and
powerpc*)

• Default version of MySQL switched to 8.4

• Default version of PostgreSQL switched to 18

• Chromium 146.0.7680.177

• Electron 40.8.3 added

• Firefox 149.0

• Firefox-esr 140.9.0

• KDE Plasma 6.6.3

• KDE Frameworks 6.24.0

• KDE Applications 25.12.3

• Qt6 6.10.2

• Ruby 3.2.10, 3.4.8, 4.0.1

• Rust 1.94.0

• SDL 3.2.30

• wlroots 0.20.0 added

• Wine 11.0

During the last quarter, pkgmgr@ ran 29 exp-runs to test various base system
changes and ports upgrades.

Cluster Administration Team

Links:
Cluster Administration Team members URL:
https://www.freebsd.org/administration/#t-clusteradm

Contact: Cluster Administration Team <clusteradm@FreeBSD.org> Contact: Philip
Paeps <philip@FreeBSD.org>

FreeBSD Cluster Administration Team members are responsible for managing the
machines the Project relies on to synchronize its distributed work and
communications.

In this quarter, the team has worked on the following:

• Regular support for FreeBSD.org user accounts.

• Regular disk and parts support (and replacement) for all physical hosts and
mirrors.

• Cluster software refresh.

• Coordinate community mirrors.

Cluster refresh

The stable/13 branch will stop being supported by the FreeBSD security-officer@
team at the end of April 2026. Several pieces of critical FreeBSD Project
infrastructure were upgraded from FreeBSD stable/13 to FreeBSD stable/14 and
FreeBSD stable/15. This work is ongoing at the end of the month.

The clusteradm team refreshes the production package builders (circa 35
physical machines) on a roughly six- to eight-week cadence. These machines run
FreeBSD current snapshots.

Other machines are upgraded on an as-needed basis, keeping up with security
fixes depending on how exposed they are.

At the time of this writing there are 146 physical machines in the cluster. We
have 42 machines on current, 17 on stable/15 and 80 on stable/14.

Most of the remaining stable/13 jails will be upgraded to stable/15.

12.x: Regular 0, Jails 7
13.x: Regular 7, Jails 33
14.x: Regular 80, Jails 263
15.x: Regular 17, Jails 4
>16.x: Regular 42, Jails 6
Total: Regular 146, Jails 313
Total installations: 459
Running -RELEASE|{-p*}: 0
Total geographic sites: 13

FreeBSD official mirrors

Current locations are Australia, Brazil, Japan (two full mirror sites),
Malaysia, South Africa, Sweden, Taiwan and United States of
America — California, Chicago, New Jersey, and Washington.

Our mirror site in Taiwan is experiencing an extended outage.

One of our mirror sites in Japan will get a complete hardware refresh in
2026Q2.

The hardware and network connection have been generously provided by:

• Cloud and SDN Laboratory at BroadBand Tower, Inc

• Department of Computer Science, National Yang Ming Chiao Tung University

• Internet Association of Australia

• Internet Systems Consortium

• INX-ZA

• KDDI Web Communications Inc

• Malaysian Research & Education Network

• MetaPeer

• New York Internet

• NIC.br

• Sonic

• Teleservice Skåne AB

• Your.Org

New official mirrors are always welcome. We have noted the benefits of hosting
single mirrors at Internet Exchange Points globally, as evidenced by our
existing mirrors in Australia, Brazil, and South Africa. If you are affiliated
with or know of any organizations willing to sponsor a single mirror server,
please contact us. We are particularly interested in locations in Europe.

See generic mirrored layout for full mirror site specs and tiny-mirror for a
single mirror site.

The FreeBSD Foundation does not fund work on the FreeBSD.org cluster.

Sponsor: Several anonymous individuals and companies Sponsor:
https://github.com/sponsors/ppaeps

Bugmeister Team

Links:
FreeBSD Bugzilla URL: bugs.freebsd.org/

Contact: Bugmeister <bugmeister@FreeBSD.org>

The Bugmeister team is responsible for ensuring that the Problem Report
software is in working order, entries are correctly categorised, and that there
are no invalid entries.

We are ending the quarter with 9548 open PRs, creeping slightly upwards in
every category from this time last year. We spent most of our time this quarter
greeting new contributors before providing them with an account. We think this
is going very nicely and has provided an increase in engagement and submission
quality, but we do think we could use a few more people on the team.

We welcomed a new member of the Triage Team, Simon Wollwage, who has been
lovingly going through the database, rebasing patches, and being kind to
contributors. Many reports have been closed or had their underlying issues
fixed from his efforts, and we thank him.

We finished updating documentation to request that proposed changes are sent as
git format patches. This will save time, increase security, and properly convey
author metadata. If we missed a spot, please let us know.

See also: https://wiki.freebsd.org/Bugzilla/SearchQueries

Projects

Projects that span multiple categories, from the kernel and userspace to the
Ports Collection or external projects.

Cyber Resilience Act (CRA) Readiness Project

Links:
Cyber Resilience Act Readiness URL:
https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness

The Foundation is running a project through 2026 to actively prepare the
FreeBSD Foundation, Project, and the community for the EU Cyber Resilience Act.
There are six main areas of focus: Security and Vulnerability Handling, SBOM
Toolchain, Public Documentation, Community Legislative Engagement, Public
Project Repository, and Communications.

Over February and March the project has moved from planning into active
delivery. Internal weekly coordination meetings are now in place, and the
Foundation’s contracted security lead, Pierre Pronchery, has joined the FreeBSD
Security Team to align the project work more closely with the FreeBSD Project’s
existing security processes.

On the regulatory engagement front, the Foundation co-signed an Open Source
Initiative letter to the European Commission supporting voluntary security
attestations, contributed to Eclipse Foundation feedback on draft CRA guidance,
and attended FOSDEM and FOSS Backstage to collaborate with other open source
communities navigating the CRA.

Technical work on the SBOM toolchain is progressing well, with early automated
SBOM generation now under testing. A public project repository has been created
to track progress transparently, a community FAQ has been published, and a
dedicated contact address is available for questions. Outreach to downstream
manufacturers has also begun.

More robust pkgbase conversion

Links:
pkgbasify URL: https://github.com/FreeBSDFoundation/pkgbasify

Contact: Isaac Freund <ifreund@freebsdfoundation.org>

The pkgbasify script is used to convert non-pkgbase FreeBSD systems to pkgbase
systems.

In the last quarter, I landed several improvements in upstream pkg, allowing
pkgbasify to become both simpler and more robust. At the same time, the
dependency of pkgbasify on the etcupdate database in /var/db/etcupdate/current
can be now be eliminated, making pkgbasify much more flexible.

These improvements will be available to end users after the pkg 2.7 release.

Sponsor: The FreeBSD Foundation

Alpha-Omega Beach Cleaning project

Links:
Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev
Alpha-Omega on GitHub URL: https://github.com/ossf/alpha-omega
FreeBSD Foundation URL: https://freebsdfoundation.org
Project repository from the FreeBSD Foundation URL:
https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

Alpha-Omega’s mission is to catalyze sustainable security improvements to
critical open source projects and ecosystems. After a successful project with
the FreeBSD Foundation in 2024 — auditing the bhyve hypervisor and the Capsicum
sandboxing framework — Alpha-Omega has selected FreeBSD again, for the Alpha
Omega Beach Cleaning project this time. This new grant consists in generally
improving the security and maintenance of third-party software within the
FreeBSD base system. The FreeBSD Foundation received the grant and has managed
and executed the project. This project is officially completed as of March
30th, 2026.

After the previous report from 2025Q4, two major objectives have been
identified:

• Import of pkgconf into the base system (see draft PR #1994 on GitHub)

• Import of pkg into the base system (see the khorben/pkg-2.6.2 branch on
GitHub)

Both objectives are nearing completion, and they were presented publicly at
AsiaBSDCon 2026 in Taiwan, during the FreeBSD Developer Summit as well as
during the conference’s Work-in-Progress session.

Monthly reporting has been submitted to alpha-omega and is available as before
on GitHub for 2025 and for 2026.

Sponsor: Alpha-Omega, The FreeBSD Foundation

FreeBSD Software Bill of Materials

Links:
spdxtool: Add parameter for using URI as SPDX id URL:
https://github.com/pkgconf/pkgconf/pull/484
spdxtool: Add cli parameter for changing SPDX id URL:
https://github.com/pkgconf/pkgconf/pull/483
spdxtool: spdxtool: Add homepage handling URL:
https://github.com/pkgconf/pkgconf/pull/475
spdxtool: Add source handling to SBOM URL:
https://github.com/pkgconf/pkgconf/pull/474
spdxtool: Add support for copyright text URL:
https://github.com/pkgconf/pkgconf/pull/473
spdxtool: Rework of License-tag SDPX expression evaluation URL:
https://github.com/pkgconf/pkgconf/pull/461
Add some stricter compiler warnings and overcome new warnings URL:
https://github.com/pkgconf/pkgconf/pull/450
libpkgconf/libpkgconf.h: Add printf-like attributes to functions URL:
https://github.com/pkgconf/pkgconf/pull/447
spdxtool: Update variables that are const to const URL:
https://github.com/pkgconf/pkgconf/pull/446
man/spdxtool.1: Add man page for spdxtool URL:
https://github.com/pkgconf/pkgconf/pull/445
Added SPDX-License-Identifiers URL:
https://cgit.freebsd.org/src/log/?qt=author&q=Tuukka+Pasanen
SPDX-License-Identifiers up-to review and waiting for upstreaming URL:
https://github.com/freebsd/freebsd-src/compare/main...illuusio:freebsd-src:update-spdx-licenses
Issue open for commenting and review: caesar: Add SPDX-License-Identifier tags
URL: https://reviews.freebsd.org/D55461
.pc file for SBOM metadata (WIP) URL:
https://github.com/illuusio/freebsd-src/tree/sbom-pkgconfig/release/sbom

Contact: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

The FreeBSD Software Bill of Materials (SBOM) project started in 2025 and
continued in 2026. Work in 2026 has focused more on the EU Cyber Resilience Act
(CRA), and the effort has shifted toward delivering a framework for FreeBSD
source.

In the first quarter of 2026, SBOM work was delivered in three categories:

• Pkgconf upstream work, especially with spdxtool-tool, which is used for
creating SPDX Lite 3.0.1 JSON-LD SBOMs from .pc-files.
Several missing features have been added and are under active development
by pkgconf contributors.
The tool is now nearly compatible with SPDX Lite 3.0.1 requirements and is
ready for general use.
Additionally, there is an effort to import pkgconf as part of the FreeBSD
source, led by Pierre Pronchery.

• Adding missing SPDX-License-Identifier to files under the FreeBSD source in
the bin, sbin, usr.bin, and usr.sbin directories.

• Creating .pc-files for SBOM. The first patch is expected to land in 2026Q2,
starting with files from bin.

If you want to help with this effort:

• Verify that SPDX-License-Identifier licenses are correct and assist with
upstreaming files.

• Verify that .pc files contain accurate information and help upstreaming
them to git.

• Assist in reviewing the pkgconf import to the FreeBSD source.

Sponsor: The FreeBSD Foundation

Laptop Testing and Integration Project

Links:
Project URL URL: https://freebsdfoundation.github.io/freebsd-laptop-testing/
GitHub repository URL: https://github.com/FreeBSDFoundation/freebsd-laptop-testing

Contact: Shreeney Ajmeri <shreeney@freebsdfoundation.org>

The goal of this project is to create a community workflow for users of FreeBSD
to easily test their laptops against, placing all tested laptops in a table,
along with a ranking system to automatically deduce which laptops are currently
the best for running FreeBSD on.

As part of the FreeBSD Foundation’s Laptop Support and Usability Project, this
workflow will prove very useful for prospective users of FreeBSD, who want to
test their laptops to see how well-supported they are. It also helps buyers who
want to purchase a laptop that is known to be well-supported by FreeBSD.

The main goal is to consolidate all FreeBSD laptop compatibility information
into one central knowledge base for the community to refer to.

During this quarter the following items were completed,

• Created a Python-based application which builds on top of the hw-probe
utility, which collects and aggregates a relevant subset of the data for
both laptop developers and end users to view.

• Developed a static-site-generation system to parse the files created by the
Python application into HTML fragments for use in the website

• Set up a GitHub Actions workflow to auto-run the parser and generate the
website upon new merge or git actions from a user

• Outlined a sub-set of relevant information created by hw-probe to be used
in the FreeBSD laptop testing workflow

• Created a pull request template for the users to follow outlining important
features of the laptop that work or not.

• Developed a scoring system to be used in the application to automatically
score laptops based on how many devices on the laptop function or not.
Added a workflow that makes manual adjustment of criteria and scores easier
for maintainers.

• Created Makefile and shell scripts to aid users in running the tests using
a simple make command within a terminal, complete with user-friendly
prompts if required applications are not installed.

• Tested all laptops and desktops in the Kitchener office with the test suite
inside the repository to verify if it works properly across both laptops
and desktops

In addition, extensive testing took place during this quarter,

• Tested the Framework Laptop 13 (AMD 7040 Series) and Lenovo Yoga 11e (Kaby
Lake) against the FreeBSD Laptop Integration Testing Guidelines on FreeBSD
16-CURRENT

• Worked on testing drm-kmod support on the Framework Desktop (Ryzen AI MAX)
, as well as s2idle (suspend-2-idle) support on the Framework Laptop.

• Created FreeBSD Handbook documentation on Wayland, including setting up
Niri, Labwc, Hyprland, and RiverWM window managers properly. Tested and
debugged Wayland support on the commited test targets, and reported bugs to
relevant developers.

• Integrated the Ly display manager into the upcoming KDE installer for
FreeBSD 15.1, allowing users to choose between SDDM and Ly.

• Evaluated the viability of GPU Passthrough on a Dell OptiPlex 7010 system
using an NVIDIA GPU

Other notes:

• Started work on testing GPU passthrough on other machines; they are yet to
arrive at the Kitchener office

• Continuing to iterate on the freebsd-laptop-testing repository and
listening to user feedback after it goes live.

• Working on iterating the laptop testing project into the freebsd.org domain

Sponsor: The FreeBSD Foundation

Desktop Script for BSDInstall

Links:
Laptop Support and Usability Project Task URL:
https://github.com/FreeBSDFoundation/proj-laptop/issues/25
Project repository URL: https://gitlab.com/alfix/kde-installer-dialogs

Contact: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>

In the past, I developed several shell scripts with graphical interfaces to
install and configure a complete desktop environment on my laptop. These
interfaces allowed users to select their preferred options. One script in
particular included GPU drivers, desktop environments, and tools for both
laptops and desktop systems. These projects are still available in public
online repositories, but they are now likely obsolete, as they have not been
used or maintained for several years.

Recently, the FreeBSD Foundation launched the Laptop Support and Usability
Project. One of the short-term goals of this project is to provide a simple
feature in bsdinstall(8), the FreeBSD system installer, to install and
configure a graphical environment. The installer should ask users whether they
want to install a desktop environment and, if so, automatically install and
configure everything needed with minimal or no user intervention. After reboot,
users should be presented with a KDE Plasma graphical login screen.

To implement this feature, I reused one of my previous scripts as a proof of
concept. It has been updated, simplified, and renamed to desktop. The script
installs and configures GPU drivers, Xorg, KDE Plasma, and SDDM. Based on the
feedback received, I introduced several improvements over the original version:

• Automatic GPU detection with a suggested video driver, since some users
selected the wrong GPU during testing. This is particularly important as
the script targets less experienced users.

• Addition of dialog-based messages to provide information, documentation,
and error reporting.

• Extra features and menus to allow users to choose certain configurations.

In the future, depending on user interest and feedback, support can be extended
to additional desktop environments and tools.

One of the main challenges was the wide variety of supported GPUs. For this
reason, I launched a call for testing, involving the community through a script
to be executed on an already installed system. The feedback and suggestions
received were very positive and valuable. Contributions are still welcome,
especially for:

• NVIDIA Optimus with recent GPUs.

• Systems with non-amd64 architectures.

A version of the script was later adapted for integration into bsdinstall and
into an installation ISO. After successful testing on both CURRENT and STABLE,
a review has been submitted to add the desktop script to bsdinstall: D56167.

Sponsor: The FreeBSD Foundation

A bhyve management GUI written in Freepascal/Lazarus

Links:
Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It
needs a bunch of tools, mostly installed on base system, and some installed
from ports/packages. The main goal is to be a desktop application with focus on
desktop users to easily and quickly setup and run virtual machines on FreeBSD
hosts.

During this quarter, there were many bugfixes and improvements to Bhyvemgr.

These are some highlights that were added:

• Add PF/NAT support

• Add -n to sudo/doas command. They will save an error to log file if the
permissions to run some apps are missing

• Add some how-to to bhyvemgr wiki

• Change RDP parameter: /log-level:off to /log-level:ERROR

• Improve aarch64 support

• Improve settings window

• Improve IPv6 support

• Improve log functionality

• Update translations

Bhyvemgr supports aarch64 from 15.x to 16-CURRENT and amd64 from FreeBSD 14.x
to 16-CURRENT. It can be compiled or installed from ports or packages with
gtk2, qt5, or qt6 interface support.

People interested in helping or supporting the project are welcome.

Current version: 1.13.1

Sponsor: https://paypal.me/alonsocbsd

Full CPUID Control for bhyve

Contact: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>

Project Overview

Ongoing work on this project aims to integrate the existing proof-of-concept
work into FreeBSD, and to add the following usability features:

• a user-friendly configuration method to override individual bits, parts or
even whole CPUID functions as needed, while keeping the rest of the host
CPUID information or a pre-defined CPUID configuration

• a user-friendly configuration method for the hypervisor signature reported
by bhyve

• a set of predefined CPUID configurations based on common x86 architecture
levels, perhaps also including a set of CPUID data for a few real CPU
models, and a user-friendly configuration method to choose one for a VM

Changes during the last quarter

Extensions to bhyvectl

The CPUID configuration prototype already implemented a new command for
bhyvectl, --get-cpuid-cfg, to query the CPUID configuration of a vCPU.

Another new command for bhyvectl has now been implemented, --get-cpuid, which
fetches CPUID values emulated for a vCPU.

There are several modes of operation of --get-cpuid:

bhyvectl --get-cpuid=<leaf>[,<index>]

This fetches the emulated CPUID value for an individual CPUID leaf and
optionally index.

bhyvectl --get-cpuid[=all]

This fetches the complete set of emulated CPUID values, for all supported
leaves and all supported indices.

bhyvectl --get-cpuid=all,p

Same as above, but the output is parsable as a set of CPUID configuration
options for bhyve.

bhyvectl --get-cpuid=all,s

Same as above, but the output is "sparse", meaning that only CPUID leaves
and indices are printed if their values on the given vCPU (with the --cpu
switch) differ from the same leaf and index on vCPU 0.

The latter two can be used to construct a baseline CPUID configuration based on
the CPUID emulation of bhyve, which can then be modified as desired.

More flexible CPUID configuration

The CPUID configuration mechanism implemented as part of the prototype has been
reworked to allow a more flexible and fine-grained configuration that does not
require the whole set of CPUID information to be specified. Here is an example
configuration:

cpuid.0x00000001=edx|=0x00040000
cpuid.0x00000003=ecx=0x01234567,edx=0x89abcdef
vcpu.1.cpuid.0x00000003=ecx|=0x10000000
vcpu.2.cpuid.0x00000003=ecx|=0x20000000
vcpu.3.cpuid.0x00000003=ecx|=0x30000000
vcpu.4.cpuid.0x00000003=ecx|=0x40000000
vcpu.5.cpuid.0x00000003=ecx|=0x50000000
vcpu.6.cpuid.0x00000003=ecx|=0x60000000
vcpu.7.cpuid.0x00000003=ecx|=0x70000000
vcpu.8.cpuid.0x00000003=ecx|=0x80000000
vcpu.9.cpuid.0x00000003=ecx|=0x90000000
vcpu.10.cpuid.0x00000003=ecx|=0xa0000000
vcpu.11.cpuid.0x00000003=ecx|=0xb0000000
vcpu.12.cpuid.0x00000003=ecx|=0xc0000000
vcpu.13.cpuid.0x00000003=ecx|=0xd0000000
vcpu.14.cpuid.0x00000003=ecx|=0xe0000000
vcpu.15.cpuid.0x00000003=ecx|=0xf0000000
cpuid.0x0000000b,0=edx=0xffffffff
cpuid.0x0000000b,1=edx=0xeeeeeeee
cpuid.0x0000000b,2=edx=0xdddddddd

The above CPUID configuration enables the Processor Serial Number (0x00000001,
EDX bit 18) feature on all vCPUs and sets a default serial of 0x01234567,
0x89abcef.

On each vCPU other than vCPU 0, it overwrites one digit of the serial number
with the vCPU ID so that each vCPU has a unique serial number.

The last three assignments does not make any sense. Leaf 0x0000000b contains
topology information in all indices, and register EDX always contains the
x2APIC ID of the vCPU. Consequently, these last three assignments will be
silently ignored.

Using x86 architecture levels

It is now possible to specify a x86 architecture level:

cpuid.archlevel=v1

This will disable all features of x86 architecture level v2 to v3, restricting
the CPU featureset to that of x86 architecture level v1.

Plans for next quarter

• The x86 architecture level support should be more robust. While a direct
configuration of CPUID information should allow to change almost
everything, for x86 architecture levels we should check whether all the
features defined in an architecture level are actually supported by the
hardware. Setting an architecture level that is not supported by the CPU
should be disallowed, or at least being warned about.

• Similar to setting a x86 architecture level, a mechanism will be
implemented to override the hypervisor identification without requiring
manually changing CPUID bits.

• Get the whole wad reviewed and committed into FreeBSD.

Sponsor: The FreeBSD Foundation

Sylve — A Unified System Management Platform for FreeBSD

Links:
Website URL: https://sylve.io
GitHub URL: https://github.com/AlchemillaHQ/Sylve
CI URL: https://sylve-ci.alchemilla.io
Discord URL: https://discord.gg/bJB826JvXK

Contact: Hayzam Sherif <hayzam@alchemilla.io>

Sylve is a modern, unified system management platform for FreeBSD. It provides
an integrated web interface for managing virtual machines (via Bhyve), Jails,
the networking around them, and ZFS storage.

The backend is implemented in Go, while the frontend is built with Svelte. The
project emphasizes a minimal system footprint. By default, it does not require
any packages outside of the base system.

At the end of this quarter, we made our first v0.1.0 release of Sylve, and at
the time of writing this article, we are at v0.2.3.

Optional runtime dependencies, required only when their respective features are
used, include:

• devel/libvirt for virtualization

• devel/qemu-tools for disk image management

• net/samba419 for SMB file sharing

• sysutils/swtpm for TPM emulation support

• dns/dnsmasq for DHCP and DNS services

The port pulls in these dependencies for convenience to the user, but by
itself, Sylve needs no dependencies to run.

Q1 Progress Highlights

Data Center / Cluster

• Improved how clusters are created and managed, making setups quicker and
less prone to errors.

• Implemented a backup solution using sysutils/zelta, which supports backing
up VMs, Jails, and custom datasets on a schedule without the need for
custom software running on the target host (except SSH and ZFS).

Jails

• Snapshots for Jails (including their configs) are now supported directly
from the Jail-specific UI.

• Added Wake-On-LAN support for Jails with VNET.

• Improved customizability of Jails by allowing users to specify a wide
variety of supported options (hooks, DevFS ruleset, metadata, etc.).

• Added support for a Ghostty (Zig/WASM)-based web terminal.

• Linux jails now support static IP configuration.

• A templating feature is now implemented for Jails; a Jail can be converted
to a template and then cloned any number of times.

• Start/Stop lifecycles and the associated UI have been significantly
improved to make use of our built-in queue system, providing a faster and
smoother user experience.

Virtual Machines

• Snapshots for VMs (including their configs) are now supported directly from
the VM-specific UI.

• 9P Filesystem support was implemented for quick sharing of folders between
guest and host.

• QEMU guest agent support was added for retrieving basic system and
networking information.

• Reboot/Start/Stop lifecycles and the associated UI have been significantly
improved to make use of our built-in queue system, providing a faster and
smoother user experience.

• Added support for a Ghostty (Zig/WASM)-based web terminal for the serial
console.

• A templating feature is now implemented for VMs; a VM can be converted to a
template and then cloned any number of times.

• CPU Pinning has been reworked significantly, specifically to add support
for multi-socket systems.

Authentication

• Passkey support was added for easy logins without the need to enter
passwords.

Utilities

• The downloader now also supports uploads.

• Queuing has been significantly improved for the downloader to make it more
performant.

General

We have also made numerous improvements to the UI/UX, performance
optimizations, and bug fixes across the platform. Some of these include:

• PCI Passthrough support has been significantly improved and now includes a
"Prepare Passthrough" button, which prepares a PCI device for passthrough,
making it available for use with VMs after a system reboot.

• Removed several NPM libraries in favor of custom-built alternatives or
vendored-in dependencies to reduce the risk of supply chain attacks.

• Made numerous performance optimizations to reduce RAM and CPU usage on the
frontend.

• Migrated the CI system from Jenkins to GitHub Actions, which now uses
sysroots to build, allowing us to achieve faster build times.

• Most of the telemetry data has been moved from the main SQLite database to
a new telemetry database. This reduces the risk of locks on the primary DB,
thereby increasing performance.

• Wrote initial documentation and deployment guides for users to get started.

Roadmap Update

• Address user feedback.

• Work on integrating more features (NFS Shares, NAT/Traffic Rules UI, etc.).

Sponsors: The FreeBSD Foundation, Alchemilla Ventures (Development), IPTechnics
LLC (Infrastructure & Testing)

AppJail, AppScripts and Sandboxed X11 Applications

Links:
AppJail on GitHub URL: https://github.com/DtxdF/AppJail
AppScript on GitHub URL: https://github.com/DtxdF/appscript
x11appjail on GitHub URL: https://github.com/DtxdF/x11appjail

Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

AppJail is an open-source BSD-3 licensed framework entirely written in POSIX
shell and C to create isolated, portable and easy to deploy environments using
FreeBSD jails that behaves like an application.

AppScript is a very lightweight and easy-to-use tool for creating
self-extracting executables.

OS-level virtualization is not as perfect as hardware-level virtualization: a
vulnerability in a device not hidden within the jail could pose a risk to the
host, but, if done correctly, it is much better than running an application
directly from the host.

Jails are the implementation of OS-level virtualization for FreeBSD. With
jails, many things can be easily restricted: limiting resources, restricting
access to /dev devices, limiting the filesystem, restricting the network, and
many other aspects. All transparently to the application running within the
jail. However, one issue, specifically with X11 applications, is the lack of
isolation. Users often misuse the xhost + trick to run an X11 application
inside the jail and display the application on the host’s X server. This poses
a security risk because, even though the X11 application runs inside the jail
and even though it does so as an unprivileged process, it can obtain a great
deal of information from the host. Therefore, a compromised application, one
with a backdoor, or simply one that collects a lot of information for
«telemetry purposes» could be a nightmare with this setup and, in the
worst-case scenario, compromise the host.

A new command has recently been implemented in AppJail to solve this problem:
appjail-x11(1). This command runs an application inside the jail but displays
it on a new X server created by Xephyr, which is already authenticated with
MIT-MAGIC-COOKIE-1. This is much simpler and lightweight than setting up an SSH
server inside the jail, creating a key pair for this purpose, connecting to the
jail, etc. However, this command is not limited to just that: you can resize
the Xephyr window, and your DE/WM will be refreshed accordingly, as this
command is capable of detecting such changes.

However, while much has been achieved with this command, the user must install
a DE/WM and the application inside the jail, and perhaps install a custom
.desktop file on the host. This can be automated using Makejails, and advanced
users will be fine with that, since they love customizing everything, but for
the average user (or even for me), what I wanted was to distribute applications
so that users would not have to do anything more than simply run the
application, and that is what x11appjail aims to solve.

x11appjail is a repository containing pre-made scripts for deploying certain
X11 applications using appjail-x11, which automates the installation of the
.desktop file, the icon, the creation of the jail via Makejails, and some
reasonable default environment variables that can be easily modified at
runtime. However, the repository actually exacerbates the usability issue: now
the user has to clone and pull updates, which may be enough for some users, but
what I wanted was reasonably good usability of the application and the ability
to easily isolate it in a jail. Therefore, I wrote appscript, which creates SFX
files in ELF format, and these are automatically created with each new release
of that repository thanks to a GitHub workflow.

Sponsor: https://www.patreon.com/appjail

daemonless: Native FreeBSD OCI Containers

Links:
Daemonless URL: https://daemonless.io

Contact: Michael Johnson <ahze@ahze.net> Contact: Jesús Daniel Colmenares
Oviedo <dtxdf@FreeBSD.org>

Daemonless is a collection of FreeBSD-native OCI images that run directly on
the FreeBSD kernel. It combines the power and security of Jails with the modern
container ecosystem—compatible with Podman, AppJail, or any OCI-compliant
runtime. No Linux virtual machines or overhead required.

Features:

• s6 Process Supervision — Proper signal handling, no zombie processes

• PUID/PGID Support — Seamless permission mapping for ZFS datasets and bind
mounts

• Multiple Tags — Choose between upstream binaries (:latest), quarterly
packages (:pkg), or rolling packages (:pkg-latest)

• Automated CI/CD — Every image built and tested automatically

Our image fleet contains more than 60 images, ranging from media managers such
as Radarr, Sonarr, Prowlarr, Lidarr, Readarr, Bazarr, and Jellyfin, to
downloaders like SABnzbd and Transmission, and even infrastructure software
such as nginx, Vaultwarden, Smokeping, and OpenSpeedTest. We even have a
complete stack for Immich!

All of these images were created using https://daemonless.io/guides/dbuild/,
the primary build engine for the Daemonless project, which has been recently
ported. It provides a unified interface for building, testing, and publishing
FreeBSD OCI container images, ensuring consistency between local development
and CI/CD environments.

In addition to deploying OCI containers using Podman and Podman-Compose, it has
recently become possible to use https://github.com/DtxdF/AppJail and
https://github.com/DtxdF/director as alternatives, thanks to their OCI
compatibility.

Kernel Benchmark, MAINTAINERS, and pkgdist

Links:

Kernel benchmark writeup URL:
https://github.com/Humanoid-Human/fbsd-work/blob/main/kernel-benchmark.md
MAINTAINERS srcmgr thread URL: https://github.com/freebsd/srcmgr/issues/21
MAINTAINERS pull request URL: https://github.com/freebsd/freebsd-src/pull/2107
pkg to distribution set converter URL:
https://github.com/Humanoid-Human/fbsd-work/pull/1

Contact: Trevor Xu <trevorxu5@gmail.com>

My work this term was split between three projects.

Kernel Benchmark

I ran several benchmarks of FreeBSD 15.0-RELEASE, FreeBSD 16.0-CURRENT (default
installation), and FreeBSD 16.0-CURRENT with kernel debugging disabled. The
purpose of this work was to provide proper measurements of the performance
impacts of kernel debug tooling. I found that the default installation of
16.0-CURRENT (i.e. with debug) was significantly slower than 15.0-RELEASE,
particularly in areas such as memory allocation. On the other hand,
16.0-CURRENT when configured correctly had performance comparable to
15.0-RELEASE in every test I ran. A full writeup is available.

MAINTAINERS Modernization

Based on the info from the srcmgr thread, I made a layout for a UCL file that
would store maintainers and paths to watch, as a replacement for the current
MAINTAINERS file. I then wrote a flua script that reads this file and can
output CODEOWNERS for GitHub or Forgejo, get the maintainers for a particular
path, get paths for a particular maintainer, etc. The pull request can be found
here.

pkg to Distribution Set Converter

Currently working on writing a shell script that can convert a pkgbase package
set into a distribution set. This would help facilitate the transition to
pkgbase.

Sponsor: The FreeBSD Foundation

LLDB Improvement on FreeBSD

Links:
LLVM Meta Issue URL: https://github.com/llvm/llvm-project/issues/180061

Contact: Minsoo Choo <minsoochoo0122@proton.me>

Due to the licensing issue with GDB (GPLv3), FreeBSD has adopted LLVM,
including LLDB, in its base system since FreeBSD 10.0. However, most kernel
developers still rely on KGDB, a patched version of a recent GDB, to debug the
kernel. This is partly a matter of personal preference (some find GDB’s command
syntax more comfortable), but there are also practical reasons: LLDB lacks
several features that KGDB provides (see below for details) and has
insufficient support even in the base system. My work aims to achieve feature
parity with KGDB by the end of April.

The improvements I have made so far are listed in the link above. Note that
small bug fixes are not included in that list.

The following are not supported: i386, arm, powerpc32, powerpc64be, and mips*.
FreeBSD 13 and earlier are also unsupported. The targeted LLVM version is 23,
although this work may be backported to FreeBSD’s in-tree LLVM and MFCed to
stable/14 and stable/15 after Dimitry Andric finishes his LLVM 21 MFV.

I started this work in late January, and it is projected to be complete by
April. Beyond feature parity, there are further possible improvements, such as
minidump2elf support and adding UUIDs to kernel and core dump ELF headers.

The biggest blocker for this project is a lack of reviewers knowledgeable in
both FreeBSD internals and KGDB internals. If you have time, please provide
feedback on my pull requests. Testers on non-x86 and non-arm64 machines would
also be very welcome. If you find any issues, please file a bug and ping me on
llvm/llvm-project.

Sponsor: The FreeBSD Foundation

Userland

Changes affecting the base system and programs in it.

Process Descriptor API completion

Contact: Konstantin Belousov <kib@FreeBSD.org>

FreeBSD offered the Process Descriptors facility for long time. Its main use is
in the Capsicum sandboxes where the handle is required to operate on an object,
and process descriptor provided such handle. Other operating systems provide
similar facility under the same name. The offered API was not complete, main
lacking part being the pdwait(2) system call, the analog of wait(2) family,
which operates on the process descriptor instead of the process id.

The described project added pdwait(2) call. Another important addition was the
pdrfork(2) call, which provides the same fine-grained support for process copy
construction as rfork(2), but also returns the process descriptor as the
handle, like pdfork(2).

After pdwait and pdrfork addition, the natural extensions for the posix_spawn
(3) facilities were possible. Now the posix_spawnattr_setprocdescp_np(3)
attribute requests that posix_spawn(3) returned process descriptor. Another
natural addition was posix_spawnattr_setexecfd_np(3) which specifies the
executable image by file descriptor instead of the name.

Together, the newly added features make the process descriptor complete and
allow the use of posix_spawn in the sandboxes.

Sponsor: The FreeBSD Foundation

Kernel

Updates to kernel subsystems/features, driver support, filesystems, and more.

ACPI Driver for System76 Laptops

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

I have been working on a dedicated driver for System76 laptops and it is now
available on CURRENT.

So far, I have added the support for:

• Battery charging thresholds. (commit)

• Keyboard brightness with backlight(8) support. (commit)

• Keyboard RGB color handling. (commit)

The only thing left is switching between dGPU and iGPU by the driver. However,
it is possible to switch without driver assistance.

Suspend/Resume Improvements

Links:
Blog URL: https://obiw.ac/s0ix/
BSDCan talk on s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Sleep testing image URL: https://people.freebsd.org/~obiwac/s0ix/
Working branch URL: https://github.com/obiwac/freebsd-s0ix/pull/15

Contact: obiwac <obiwac@FreeBSD.org>

Suspend-to-idle and support for S0ix sleep is in the process of being added to
FreeBSD.

This will allow modern Intel and AMD laptops, some of which do not support ACPI
S3 sleep, to enter low power states to increase battery life.

Most revisions have now been committed at this point, including the new
acpi_spmc driver and s2idle support. The only remaining things to land are USB4
suspend support and the s2idle loop (but that requires some more discussion and
investigation). See revisions D52861 and D54410 respectively.

Many bugs have been fixed, but there still is an issue where the system will
sometimes lock up a few seconds after resuming. This was narrowed down to the
NVMe drive not waking correctly after being suspended — still requires further
investigation.

Work on an Intel PMC driver has started: D54881 This already allows for reading
residency in the deepest possible S0ix state on Intel CPUs.

Work has started on a new generic power management interface: D55508 This is
needed as s2idle is not an ACPI power state, and the only (modern) mechanism
for power transition requests is the ACPI ioctl interface. It has not yet
landed because we might end up changing or even removing the distinction
between sleep types and sleep state transitions.

Sponsor: The FreeBSD Foundation

Hibernate (aka Suspend-to-disk)

Links:
Code for the initial prototype for saving the system image URL:
https://github.com/OlCe2/freebsd-src/tree/oc-hibernate
Design document on the loader part of the resume process URL:
https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=

Contact: Olivier Certner <olce@FreeBSD.org>
Contact: Konstantin Belousov <kib@FreeBSD.org>

Work is ongoing to have FreeBSD support hibernate (suspend-to-disk), without
BIOS/firmware assistance to save the current machine state, for amd64
UEFI-booted machines.

The first phase was to make a prototype that saves a system image, at the
moment putting aside consistency matters, so that parallel work can start on an
EFI application meant to restore and bootstrap the saved image (Konstantin
Belousov is working on this part). This phase was completed in March. A
significant refactoring, in particular of the underlying dump infrastructure,
needs to occur before that experimental code can be committed.

The main next phase is to ensure consistency of the saved system image, so that
the system is viable once restored. In a nutshell, the biggest constraint here
is that we must ensure that no more I/O is in flight for several reasons, which
consists in first ensuring that no more I/O requests can be created and then
draining the existing requests. In particular, on-going DMA accesses could
change memory while it is being saved, leading to out-of-date caching in the
saved image. Also, if resuming fails (because of, e.g., some hardware
consistency issue), I/O that did not reach stable storage would be lost,
whereas application or filesystem code would expect them to be committed (loss
of consistency). We have started identifying the subsystems that need attention
and analyzing which changes are required in them (e.g., bus, GEOM, disk
drivers).

The phase after is to determine how to finally save the system image without
tainting the consistency, as this operation itself modifies kernel memory. A
first high-level possibility is to take a snapshot of memory after ensuring
stability, and then resume normal operation to save the pages in their state at
the moment the snapshot was taken. There are several possible refinements, such
as forefront or lazy copying, with different implementation strategies, and
thus characteristics and requirements. Advantages of snapshotting include the
ability to use regular kernel code to save the image, with all available
transformations supported. Drawbacks are higher memory consumption, although
that depends a lot on the chosen implementation strategy and seems to be
mitigable for a large part, and possibly some complications at very low levels
of the kernel. An alternative which is under study is not to snapshot, but
instead ensure that sending the image to disk only modifies state that will be
effectively reset on resume. This alternative requires implementation of
selective suspend, but otherwise we expect that a large part of the existing
dump-on-panic code would be reusable. We are currently digging into the
different options to better understand their feasibility and the trade-offs
involved.

Sponsor: The FreeBSD Foundation

Collaborative Processor Performance Control (CPPC)

Contact: ShengYi Hung <aokblast@FreeBSD.org>
Contact: Olivier Certner <olce@FreeBSD.org>

Collaborative Processor Performance Control (CPPC) is a standard introduced by
ACPI to allow the OS to manage performance and, conversely, efficiency levels
of CPUs thanks to an abstract performance scale in general uncorrelated to and
more fine-grained than mere frequency levels. Intel and AMD have been providing
CPU implementations in support of ACPI CPPC for several years now.

FreeBSD had been supporting enabling CPPC but only for Intel processors and
allowing to manage a useful but very limited subset of its functionality,
thanks to the hwpstate_intel(4) driver added in 2020. Hardware autonomous
selection of the performance target depending on the workload is forcibly
enabled, and only the main corresponding hardware tunable, called Efficiency/
Performance Preference (EPP), is exported to the administrator via a sysctl(8)
knob.

We have added support for AMD CPPC’s implementation in the existing
hwpstate_amd(4) driver which, contrary to hwpstate_intel(4), so far managed
only "regular" P-states. The driver exports 4 sysctl(8) knobs: Minimum
performance, maximum performance, desired performance and EPP. Minimum, maximum
and desired performances are values between 0 and 255, but only a sub-range may
have an effect depending on the hardware. Initial values of minimum and maximum
performances are set to the effective sub-range bounds as instructed by the
platform (if available). The EPP control serves to express a bias towards
efficiency or performance, and is a value between 0 (maximum performance
preference) and 255 (maximum efficiency preference). The desired performance
may be set to any value between minimum and maximum performance, or to the
special value 0 to enable hardware autonomous selection of target performance
by the hardware depending on the current workload. The minimum performance,
maximum performance and EPP controls apply regardless of whether autonomous
selection is enabled or a specific desired performance specified. Note that the
effect of each combination of these values depend on the CPU model, and we have
already been able to observe wildly different behaviors on a few ones.
Therefore, you should expect to have to experiment to find the values adapted
to your use cases on a given machine.

hwpstate_amd(4) is included by the GENERIC kernel (through cpufreq(4)) and uses
CPPC if the CPUs support it unless explicitly instructed otherwise (through the
machdep.hwpstate_amd_cppc_enable tunable). Consequently, in order to avoid
performance regressions, for the time being we have decided to set the
above-mentioned controls for maximum performance, as this is the default
behavior for traditional P-state support and also that of any other cpufreq(4)
driver except for hwpstate_intel(4) (which currently forces hardware autonomous
selection and sets EPP to 0x80 (50%) by default). This may be revised later
depending on whether we can reliably determine if the running computer is a
laptop.

Next steps are:

1. Modify hwpstate_intel(4) to be on par with hwpstate_amd(4)'s CPPC support
in terms of functionality and default behavior. This includes:

□ Better error-handling and debugging output

□ Exporting knobs for all the above-mentioned controls

□ Change the scale of EPP (from percents to an 8-bit value)

□ Change the default values

2. Write a manual page for hwpstate_amd(4) (in the meantime, the explanations
here and the embedded sysctl(8) knobs' documentation should be enough).

3. Teach powerd(8) the CPPC control knobs and some simple policies on how to
set them.

4. Teach cpufreq(4) about the abstract performance values, to provide a
unified interface to retrieve or set them.

5. Make cpufreq(4) support per-CPU settings.

6. Select default control values based on the platform type (probably from
ACPI’s FADT's Preferred_PM_Profile field).

7. Possibly move powerd(8) policies to kernel space.

Sponsor: The FreeBSD Foundation

Audio Stack Improvements

Contact: Christos Margiolis <christos@FreeBSD.org>

I have been working on the audio stack since 2024Q1. Below is a list of the
previous status reports:

2024Q1 URL:
https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements
2024Q2 URL:
https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements
2024Q3 URL:
https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements
2024Q4 URL:
https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements
2025Q1 URL:
https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements
2025Q2 URL:
https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements
2025Q3 URL:
https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements
2025Q4 URL:
https://www.freebsd.org/status/report-2025-10-2025-12/#_audio_stack_improvements

Important work since last report:

• FreeBSD Journal article published.

• sound(4) and virtual_oss(8) cleanups, fixes and improvements.

• libxo support for sndctl(8).

• Started implementing DSD format and DoP support.

• Started implementing a bluetooth device management utility.

You can also follow the development process on the FreeBSD Foundation’s
status-updates repository, where I post weekly reports.

Sponsor: The FreeBSD Foundation

LinuxKPI 802.11 and Native Wireless Update

Links:
Support the MediaTek Wireless cards URL:
https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Support the Realtek Wireless cards URL:
https://github.com/FreeBSDFoundation/proj-laptop/issues/99

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

This report focuses on the efforts using permissively licensed Linux wireless
drivers, mostly unmodified, on FreeBSD, as well as preparing the native
net80211 stack for support of newer standards.

Driver updates

All LinuxKPI based wireless drivers were updated to Linux v6.19 in main and
stable/15.

This includes * the shipping drivers Intel iwlwifi(4) mvm/mld, Realtek rtw88(4)
and rtw89(4), * the Mediatek mt76 driver which is a work in progress, * the
three Qualcomm Atheros drivers ath10k, ath11k, and ath12k, which are TODO, as
well as * the Broadcom brcmfmac, which compiles and loads firmware but is
lacking the cfg80211 compat shim and some netdev work.

Intel iwlwifi support

In order for the iwlwifi(4) driver update to be applied a few FreeBSD specific
adjustments were made to allow the mld sub-driver to load properly. Also
multiple bug fixes were worked out.

Realtek rtw88 and rtw89 support

After the driver updates it turned out that our chandef emulation needed to be
more elaborate. In the follow-up further problems were discovered related to
the fact that some rtw88 drivers can fail the hardware scan needing a fallback
to software scanning. Lastly the two rtw88 chipsets 8821c and 8822b seem to
often have a 6s delay when we are preparing to authenticate. It is unclear why
the firmware fails in those cases but in the end I decided to leave this
problem alone and try to get the 802.11n and 802.11ac updates in next (before
15.1-R hopefully) and only then go back to these chipsets and see what we can
do.

Mediatek mt76 support

MT7921/7922 and MT7925 are the primary chipsets to work on currently. After the
driver update some DMA32 problems along with page_pools got sorted. The
drm-kmod changes prepared for the switch from native vm_page to Linux struct
page were thankfully committed. This we allow me to get a testing version out
to people more easily. MT7925 also revealed an insufficiency in our LinuxKPI
IDR implementation, which more or less was documented there from day one. This
will need a complete rework to avoid problems with accesses to already
destroyed entries which can happen in Linux. I have also started to rack up
further chipsets for testing. 802.11n and 802.11ac support will mostly come
along with the Realtek work.

Broadcom brcmfmac

The Broadcom brcmfmac driver is compiling for PCIe and loading firmware (with a
minor work around for arm64). We are now lacking some cfg80211 and netdev
LinuxKPI compat work in order to create the interface and drive wireless.

QCA support

While ath10k is mostly sorted for station mode, ath11k and ath12k need more
work to compile again and an implementation for the MHI and other bits as
needed.

LinuxKPI USB support

The LinuxKPI USB implementation has been sitting there for more than a decade.
I already put out a call for any users last years and again this year without
any reply. I do have an overhauled version which allows Realtek, Mediatek QCA
ath10k, and Broadcom brcmfmac USB chipsets to compile. The latter two are
mostly irrelevant with old, and little actual USB dongles available. Realtek
and Mediatek attach and do pass packets but need a bit more work on stability
and clean teardown.

There is one blocker on this in that the (old and new) LinuxKPI USB
implementation is intermingle our native USB stack leading to conflicts. There
is work in progress to resolve this and two possible ways have been identified
but there is a 15 year old change in the way that first needs to be understood
and cleaned up.

LinuxKPI SDIO support

The LinuxKPI SDIO support has been sitting in my development tree for a good
year and was done mostly for Realtek rtw88. Broadcom will need a few more
placeholders to be filled, but that should not be too hard. Interrupts need to
be finalized and speed upgrade support pulled in from someone else’s work in
progress. My plan is to get it into the tree as-is as soon as USB is out of the
way for people to help testing and finalizing it.

Native net80211

Thanks to the Ports Management Team for running an exp-run (experimental test
build). I prepared a patch in order to identify all ports using the net80211
ioctl interface. This is needed in order to minimize breakage of upcoming ioctl
interface changes upfront.

Check PR 293016 for details.

Other

I have given an update on most of this during the March LDWG (Laptop Desktop
Working Group) call. See LDWG Wiki Page for more information.

Sponsor: The FreeBSD Foundation

Removal of RFC 2675 Support

Contact: Tom Jones <thj@FreeBSD.org>

The Jumbo Payload Option is an IPv6 extension header intended to support packet
sizes in excess of 65,735 octets. FreeBSD gained Jumbo Payload support from the
KAME project, but not real networks ever carried support.

As part of modernising the IPv6 stack Jumbo support has been removed. As far as
we can tell it has never been possible to use this support with a FreeBSD host.

Sponsor: The FreeBSD Foundation

GENEVE Tunnel

Links:
Add Support for Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Since the last report, I have broken the GENEVE implementation down into many
smaller revisions to make it easier to review:

• Implement the geneve kernel module D54172

• Integrate geneve support via netlink in ifconfig(8) D55184

• Include geneve parameters in ifconfig D55181

• Create the geneve(4) manual D55182

• Add geneve tests D55183

• Update ECN(9) tunneling functions to follow RFC 6040 D53516

• Update geneve to comply with RFC 6040 D55186

You can help to speed up the process by reviewing and providing feedback on
phabricator.

Architectures

Updating platform-specific features and bringing in support for new hardware
platforms.

drm-kmod: Build and run on ARM64 with 16.0-CURRENT

Links:
drm-kmod: Build and run on ARM64 with 16.0-CURRENT URL:
https://github.com/freebsd/drm-kmod/pull/402

Contact: Dmitry Salychev <dsl@FreeBSD.org>

I have successfully built and run graphics/drm-66-kmod with those patches on my
Honeycomb LX2 with Radeon RX 460. With these patches 6.6-lts could be a
substitute for anyone who relied upon retired graphics/drm-510-kmod.

FreeBSD Driver Development for BananaPi-R64/R2-PRO

Links:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi

Contact: Martin Filla <freebsd@sysctl.cz>

R64 Introduction

The Banana Pi R64 is a MediaTek MT7622-based development board (ARM Cortex-A53,
dual-core ~1.35 GHz) featuring 4× Gigabit LAN, 1× Gigabit WAN, Wi-Fi (4×4n),
Bluetooth 5.0, and multiple peripheral interfaces (UART, SPI, I²C, GPIO, SATA,
mini-PCIe, eMMC, etc.).

Current State of FreeBSD Support R64

Implemented so far:

• UART driver

• Clock management (clocks)

• Pinctrl

• Storage controllers (eMMC/SD/MMC) driver

• Ethernet Switch mt7531 driver

• Ethernet mt7622 driver

• XHCI driver

• Watchdog driver

• RTC driver

• RNG driver

• Pciecfg driver

• SysIRQ driver

Development roadmap R64

Implement missing drivers:

• USB3 / T-PHY

• SATA / AHCI / T-PHY

• Wi-Fi (likely MediaTek MT7615)

• GPIO subsystems

• I2C

• SPI

• PWM

• PCIE

Work in progress drivers: - T-PHY

R2-PRO Introduction

The Banana Pi BPI-R2 Pro is the next generation smart router development board.
It is powered by Rockchip RK 3568 processor. Onboard 2GB LPDDR4 memory and 16GB
eMMC storage, and supports 2 USB 3.0 interface, 5 gigabit network port. M.2
key-E and mini PCIe interface, 2 mipi DSI interface (one can change to LVDS by
software), 1 CSI camera interface, 1 HDMI output.

Current State of FreeBSD Support R2-PRO

Implemented so far:

• UART driver

• Clock management (clocks)

• Pinctrl

• GPIO

• Storage controllers (eMMC/SD/MMC) driver

• XHCI driver

• Watchdog driver

• PCIE driver

Development roadmap R2-PRO

Implement missing drivers: - HDMI - MIPI - USB3

Work in progress drivers: - AHCI/SATA - PCIE

NXP DPAA2 support

Links:
Bug 292006 - dpni doesn’t behave properly in a bridge URL:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292006
dpaa2: Setup interface caps on attach URL: https://reviews.freebsd.org/D53436
dpnaa2: announce transmit checksum support URL:
https://reviews.freebsd.org/D54809
dpaa2: Perform bus_dma pre-write sync before enqueue operation URL:
https://reviews.freebsd.org/D56144
dpaa2: dpaa2_ni_rx() RX checksum EN/ERR information for L3/4 URL:
https://reviews.freebsd.org/D55320
dpaa2: Extract frame-specific routines to dpaa2_frame.[h,c] URL:
https://reviews.freebsd.org/D56315
dpaa2: Extract checksum statuses on ingress URL:
https://reviews.freebsd.org/D56383
dpaa2: ni: add more stats and link information URL:
https://reviews.freebsd.org/D55321

Contact: Michael Tuexen <tuexen@FreeBSD.org>
Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: Dmitry Salychev <dsl@FreeBSD.org>

What is DPAA2?

DPAA2 (Data Path Acceleration Architecture Gen2) is a hardware-level networking
architecture found in some NXP SoCs which contains hardware blocks including
Management Complex (MC, a command interface to manipulate DPAA2 objects), Wire
Rate I/O processor (WRIOP, packets distribution, queuing, drop decisions),
Queues and Buffers Manager (QBMan, Rx/Tx queues control, Rx buffer pools) and
others. The Management Complex runs NXP-supplied firmware which provides DPAA2
objects as an abstraction layer over those blocks to simplify access to the
underlying hardware.

Done

39d4094173f9 ("epair: add support for checksum offloading") revealed several
issues in the DPAA2 drivers, sparked investigations conducted by tuexen@ and
dsl@ and eventually led to the changes accumulated under the bug 292006:

• HW checksum offloading was not properly enabled when the dpaa2_ni driver
was attached despite being declared and enabled on the dpni interface
(fixed in a731cb93a662)

• dpni (DPAA2 network interface) did not properly announce TX checksum
offloading (fixed in f31336b3e314)

• Without a proper synchronization payload of the egress TCP segments can be
corrupted as tuexen@ described in 292006#c31 (fixed in 5812415bee55)

Work in Progress

• bz@ prepared code to extract information about calculated checksums from
the hardware annotations of the ingress frames in D55320, but dsl@ asked to
properly define structures needed for the frame annotations which led to
dpaa2_frame.[h,c] introduced in D56315 and refined in D56383

• bz@ significantly extended dpni sysctl(9) including new interface counters
and link state information in D55321

Sponsor: Traverse Technologies (providing Ten64 HW for testing)

amd64 FRED support

Links:
Intel FRED specification before SDM URL:
https://www.intel.com/content/www/us/en/content-details/819481/
flexible-return-and-event-delivery-fred-specification.html + D55829 amd64: FRED
support URL: https://reviews.freebsd.org/D55829

Contact: Konstantin Belousov <kib@FreeBSD.org>

Support for FRED AKA Flexible Return and Event Delivery feature of the very
modern amd64 platform was implemented. FRED is the complete revamp of the
hardware interface to report exceptions, interrupts, and system calls to the
operating system, and the way operating system returns control from the handler
to the interrupted code. The goal for designing FRED was to get rid of the
layers of compatibility features and bugs that accumulated in the existing way,
let us call it IDT based event delivery.

FRED specification is now included into the Intel SDM revision 90. AMD seems to
be committed to provide FRED on some future implementations.

As such, FRED support requires the new code path for event handlers. The nice
structuring of the FRED allows to have minimal assembly trampolines there,
moving most of the dispatch to the C code.

The implementation of the FRED handler was relatively simple, and required much
less time than I initially thought. It shows how good and natural the proposed
interface is.

The testing so far was only done on the Simics emulator. FRED should be
supported by the newly released Intel Panther Lake CPUs, but I do not have
access to the real hardware.

Sponsor: The FreeBSD Foundation

Support for the Allwinner H616 SOC Family

Contact: Tom Jones <thj@FreeBSD.org>

The Allwinner H616 family of devices (H616, H616 and H700) are a series of
small, but powerful SOCs with powerful media support. These are found in a
number of TV Boxes, handheld devices and single board computers.

FreeBSD now has support for most peripherals and has been tested with the
Orange Pi 2. There is a yet unknown issue with the Ethernet controller, but
this is under investigation. Graphics support requires drm and this has not yet
been explored. The video device is not support on u-boot or Linux as a
framebuffer console.

Sponsor: The FreeBSD Foundation

Cloud

Updating cloud-specific features and bringing in support for new cloud
platforms.

FreeBSD on EC2

Links:
FreeBSD 15.0-RELEASE AMIs URL:
https://www.freebsd.org/releases/15.0R/ec2-ami-ids/release/

Contact: Colin Percival <cperciva@FreeBSD.org>

FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2
instances.

A list of EC2 AMIs for FreeBSD 15.0-RELEASE has been added to the FreeBSD
website. This page includes javascript to allow the list to be filtered by
region, architecture, flavour, and root filesystem.

A process is now in place for publishing updated EC2 AMIs in response to
security advisories; we now have FreeBSD 15.0-RELEASE-p5 AMIs and anticipate
typically having updated AMIs in place within a few hours of advisories being
published. The AMI IDs for these are published via the SSM Parameter Store and
the FreeBSD website. At present there is no mechanism in place for building
updated AMIs for 14.x releases.

An issue causing the ena(4) driver’s I/O interrupts to all land on CPU 0 on
arm64 systems has been fixed in main. The fix should be present in 15.1-RELEASE
(June) and 14.5-RELEASE (September).

An issue causing the ena(4) driver to not attach when FreeBSD boots on
r8i.96xlarge instances has been fixed in main. The fix is expected to be
present in 15.1-RELEASE (June) and 14.5-RELEASE (September).

Sponsor: Amazon
Sponsor: https://www.patreon.com/cperciva

STACKIT Cloud Integration on FreeBSD

Links:
STACKIT URL: https://stackit.com/
STACKIT CLI URL: https://github.com/stackitcloud/stackit-cli

Contact: Robert Gogolok <gogolok@gmail.com>

I am working to ensure FreeBSD is a first-class platform for managing resources
on STACKIT, the sovereign European cloud. The goal is to provide the BSD
community with native, reliable access to STACKIT’s IaaS and PaaS tools.

Native Binaries: In addition to the existing sysutils/stackit port, native
FreeBSD binaries (amd64/arm64) are now included in every official upstream
release.

Upstream Contributions:

• PR #1048: Added logic to ship native FreeBSD binaries via goreleaser.

• PR #1243: Added support for opening authentication URLs on FreeBSD.

Future Work:

• Ensure the official Terraform Provider for STACKIT functions correctly on
FreeBSD.

Containers and FreeBSD: Cloud Native Buildpacks

Links:
Cloud Native Buildpacks (CNBs) URL: https://buildpacks.io/
GitHub Buildpacks repository URL: https://github.com/buildpacks/pack

Contact: Robert Gogolok <gogolok@gmail.com>

Cloud Native Buildpacks (CNBs) transform application source code into container
images. Those images can run on any cloud. With buildpacks, organizations can
concentrate the knowledge of container build best practices within a
specialized team, instead of having application developers across the
organization individually maintain their own Dockerfiles.

Since the last report in 2025Q1, the project has transitioned from experimental
support to official binary availability:

• Both the primary CLI tool pack and the core lifecycle component now ship
FreeBSD binaries with every new upstream release.

• A new port for the CLI, sysutils/pack, has been submitted (PR 292952). This
will allow users to install the tool via pkg install pack once committed.

• The official buildpacks/samples repository now includes a Work-In-Progress
pull request (PR #201) for FreeBSD.

The next steps focus on lowering the barrier to entry for developers and
improving the automation of the FreeBSD build path:

• Seek a FreeBSD ports committer to review and land the new port sysutils/
pack into the ports tree.

• Address a known issue in pack builder create where the tool incorrectly
attempts to use non-FreeBSD URLs for certain binary downloads.

• Investigate creating Paketo-style buildpacks specifically for FreeBSD. This
would provide 'zero-config' builds for popular languages (e.g., Go) that
produce FreeBSD-native binaries within containers.

Documentation

Noteworthy changes in the documentation tree, manual pages, or new external
books/documents.

The FreeBSD Russian Documentation Project

Links:
The FreeBSD Official Website in Russian URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
The FreeBSD Russian Documentation Project site URL:
https://github.com/freebsd-doc-ru/freebsd-doc/discussions

Contact: Andrey Zakhvatov <andy@FreeBSD.org>
Contact: Vladlen Popolitov <vladlen@FreeBSD.org>

The FreeBSD Russian Documentation Project’s current goal is to provide
up-to-date Russian translations of the most important parts of the FreeBSD
documentation (FAQ, Handbook, website content). It is essential to support
Russian-speaking users with high-quality official technical materials and to
increase the adoption of the operating system worldwide. We hope this
initiative will gain support within the Russian-speaking FreeBSD community and
lead to an increase in translated materials.

During the last quarter:

• 100% of the text in Weblate has been translated, including the new "FreeBSD
Accessibility Handbook".

• The article Implementing UFS Journaling on a Desktop PC has been rewritten
and expanded with additional information, including updates on Soft Updates
with journaling.

• The Russian language section of www.FreeBSD.org/ru has been fully
translated, with 100% of its pages now available in Russian.

• For the FreeBSD 14.4 release, the complete set of release documentation
(release notes, errata, etc.) has been translated into Russian in a timely
manner alongside the English originals.

• The project to translate FreeBSD man pages has been initiated and is in its
very early stages. Preliminary examples can be found at GitHub.

Plan for the next quarter:

• Continue the ongoing project to translate FreeBSD man pages.

Check the official translation guide if you would like to help.

We would appreciate your assistance with translating the following materials:

• Web pages

• Man pages

Ports

Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.

KDE on FreeBSD

Links:
KDE/FreeBSD initiative URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Contact: KDE on FreeBSD Mailing List <kde@FreeBSD.org>

The KDE on FreeBSD project packages CMake, Qt, and software from the KDE
Community, for the FreeBSD ports tree. The software includes a full desktop
environment called KDE Plasma (for both X11 and Wayland) and hundreds of
applications that can be used on any FreeBSD machine. The KDE team is part of
desktop@ and multimedia@ teams, building the software stack to make FreeBSD
beautiful and usable as a daily driver graphical desktop workstation.

Infrastructure

Qt6, PyQt6, and PySide6 were updated to 6.10.2. The ports for Qt 6.11.0 are
available for testing in the development branch.

KDE Stack

KDE Frameworks, Plasma, and Gear release happen very regularly. KDE team lands
these updates shortly after their upstream release.

• KDE Frameworks ports were updated to 6.24.

• KDE Plasma Desktop was updated to 6.6.3.

• KDE Gear was updated to 25.12.3.

The recent Plasma update has revealed a bug in the FreeBSD implementation of
timerfd(2) which causes high CPU usage in plasmashell. The bug has been already
fixed in FreeBSD-CURRENT and merged to affected stable branches.

Related Ports

The KDE team maintains 730 ports and updates them all as needed. According to
portscout 4% of ports are outdated.

GCC on FreeBSD

Links:
GCC Project URL: https://gcc.gnu.org/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/
GCC 14 release series URL: https://gcc.gnu.org/gcc-14/
GCC 15 release series URL: https://gcc.gnu.org/gcc-15/
GCC 16 release series URL: https://gcc.gnu.org/gcc-16/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

This quarter we have three main pieces of news.

In January we investigated why GCC 16 weekly snapshots stopped compiling since
the last snapshot of November. It took many eyes to understand what happened,
but eventually the problem was understood and a fix was committed upstream in
February. The details can be found in the upstream bug report. Thanks to all
people who helped, in particular to Mark Millard and Dimitry Andric.

At the moment lang/gcc16-devel does not build on arm64. Unfortunately I have
not found the time to really look into this yet, but I hope to be able to do it
soon. PR 294062 is the bug report that tracks the issue.

The process to get GCC_DEFAULT=15 has started. The GCC_DEFAULT=14 update is
still recent and GCC 14 is actively supported, so there is no hurry to get this
completed; but since those updates tend to be long I have already started it.
Thus this is not my top priority at the moment: it is is where I put my energy
when I have spare cycles, for now.

Valgrind: stabilization, FreeBSD 16 fixes and additions

Links:
Valgrind Home Page URL: https://www.valgrind.org/
Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html

Contact: Paul Floyd <pjfloyd@wanadoo.fr>

When FreeBSD 14.4-RELEASE came out and all went smoothly I thought that there
would be little to say for this quarterly status report. Then I started using a
couple of 16.0-CURRENT machines that are part of the GCC server farm. There I
saw several issues. At first there were many more failures than I would
normally expect. A bit later the servers were updated and Valgrind broke quite
badly, asserting early on in start up. Some of these issues were the usual high
maintenance expected with Valgrind. A new Helgrind suppression was required for
internal locks used by pthread_create. The servers were built and installed
from source which affects the error callstacks occasionally. The Valgrind
regression tests are quite sensitive to that kind of change and some extra
filtering was required. The asserts were caused by incorrect assumptions in
Valgrind that are used when the tool reads its own binary, mainly to enable it
to print its own callstack if there is a crash. The final problem was caused by
a change in the way that library split debug files files are produced.

Overall, this is more of a stabilization release. There are relatively few new
features.

Valgrind 3.27 is due out at the end of April 2026 and devel/valgrind will be
updated shortly after that.

Here is a list of bugfixes since my last report, Q3 2025.

• Internal cleanup of syscall arg handling.

• More checking during client stack creation.

• Some tweaks to the default suppressions.

• Added syscall wrappers for kexec_load, pdwait, renameat2

• Syscall pdrfork added with flag "not implemented" (rfork-like syscalls are
very difficult to implement in Valgrind).

Improve OpenJDK on FreeBSD

Links:
Project description URL:
https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Project repository URL: https://github.com/freebsd/openjdk
Upstream BSD port repo URL: https://github.com/openjdk/bsd-port

Contact:
Harald Eilertsen <haraldei@FreeBSD.org>
FreeBSD Java mailing list <freebsd-java@lists.freebsd.org>

The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and
FreeBSD/arm64.

Java is an important runtime environment for many high performance, critical
enterprise systems. Making sure Java based applications run correctly and
efficiently on FreeBSD is important to ensure that FreeBSD will continue to be
a viable and attractive platform for enterprises, as well as businesses and
organizations of all sizes.

In this quarter the following issues/milestones were reached:

• Updated OpenJDK 25 port to version 25.0.2.

• Fixed an issue with building headless OpenJDK 25 variants when no xorg libs
were present.

• Reworked the way OpenJDK ports are bootstrapped on FreeBSD:

□ D54683: OpenJDK 8-20

□ D54731: OpenJDK 21-25

• Fixed and improved Serviceability Agent for FreeBSD in mainline BSD port:

□ Undo breakage caused by upstream macOS port.

□ Fixed obtaining stack traces from threads in process being traced.

□ Fixed spurious issue where symbol lookup of native symbols from shared
objects would sometimes fail.

□ Simplified function for reading arbitrary memory from traced process.

• Enabled building/installing the Hotspot Disassembler (HSDIS) for FreeBSD.
This is needed for some tests for Aarch64 to check that Hotspot generates
the correct instruction sequences in various environments. Only supporting
the llvm backend for now, though there is no reason to believe the others
would not work.

• Synced ThreadWXEnable implementation with macOS. This enables Hotspot to
toggle Write/Execute access to memory segments so that it can generate code
to later be executed on Aarch64. Just a minor tweak so we align with the
API used by the macOS code, even though our implementation is different.

• Backported BSD related changes from mainline to OpenJDK 25 and OpenJDK 26
ports.

• Added new port for OpenJDK 26. Thanks to Greg Lewis and Kurt Miller for
helping.

• Merged first PR into upstream BSD port repo!

Other notes:

• Started work on updating OpenJDK 25 to version 25.0.3, scheduled for mid
April release.

• I will be talking about the project and my experience working on it at the
foss-north conference in Gothenburg, Sweden, on April 28.

Sponsor: The FreeBSD Foundation

Make openjdk21 the default JAVA_VERSION

Links: Issue 272855 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=
272855 Sheet tracking Work in Progress URL:
https://docs.google.com/spreadsheets/d/17hmRQ0ShY4SHHVEkQBVxqK2G88fPZLriTzO26zXdjC4/edit?usp=sharing

Contact: Ronald Klop <ronald@FreeBSD.org>

Having a vivid Java environment is useful for all kinds of applications of
FreeBSD.

The default JAVA_VERSION in FreeBSD ports is changed from 8 to 21 on February
26th. This was a major step in versions. So quite some work was involved. This
is all done now.

All ports known to break were fixed and no regressions have been reported
since. The 2026Q2 ports branch will be the first stable ports branch having
OpenJDK 21 as the default Java version.

• A big thank you to all people involved

• Work has been started to make 25 the new JAVA_DEFAULT in main during Q2

Make openjdk25 the default JAVA_VERSION

Link: Issue 293559 URL:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293559

Contact: Ronald Klop <ronald@FreeBSD.org>

Java is an important environment for running some application on FreeBSD. The
OpenJDK ports are actively maintained and up to date. Since October 2025
OpenJDK 25 LTS is available in the ports tree.

Building on the groundwork of moving ports to OpenJDK 21 the switch of
JAVA_DEFAULT to 25 is a much smaller step. Most Java ports compile and run
without changes. Only a handful of ports need some fixes, which is currently in
progress.

The work is being tracked in PR 293559.

I think it is reasonable to have the ports in shape for the JAVA_VERSION=25
setting in the second quarter of 2026.

Plan: * An exp-run is requested * Check the last ports and create a PR or
commit * Commit the PRs that are timing out on maintainer feedback * Maybe ask
for another exp-run * If done, increase JAVA_VERSION

Wazuh on FreeBSD

Links:
Wazuh URL: https://wazuh.com

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>
Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

Wazuh is a free and open source platform used for threat prevention, detection,
and response. It is capable of protecting workloads across on-premises,
virtualized, containerized, and cloud-based environments.

Wazuh solution consists of an endpoint security agent, deployed to the
monitored systems, and a management server, which collects and analyzes data
gathered by the agents. Besides, Wazuh has been fully integrated with the
Elastic Stack or OpenSearch Stack, providing a search engine and data
visualization tool that allows users to navigate through their security alerts.

A lot has happened this quarter. Numerous improvements and bug fixes to enhance
FreeBSD’s support with this excellent XDR/SIEM and security platform.

• We have created a repository on GitHub to centralize the work and reduce
patches in the manager and the agent. Links: Repository, b1f5298

• Python bundle has been updated to 3.11.15. Link: c941e5b

• An issue that prevented wazuh-manager from starting when the MYSQL option
was enabled has been fixed. Link: c941e5b

• A parsing issue in sysinfo’s getPorts() function has been fixed. Link:
35fcd6a

• Support for FreeBSD has been added to asyncinotify library that prevents
Wazuh API starting correctly. Link: 35fcd6a

• Now Wazuh uses OpenSearch Dashboards 2.19.4. Link: b1f5298

• sysinfo module can now obtain users and groups information. Link: e9cebac

• An issue between the agent and the manager that prevented a successful
active state for TCP connections has been fixed, and now this protocol is
the default instead of UDP. Link: 055d5c9, 508a8c8

• FreeBSD SCA, decoders and rules files were updated, fixing conflict issues.
Links: 055d5c9, 508a8c8

• A problem with Python scripts in the manager prevented their correct
execution when the CRYPTOGRAPHY_OPENSSL_NO_LEGACY environment variable is
not set. Link: 8bd6c77

• The sysinfo’s getSerialNumber() function has been improved, so the manager
and the agent can now use the kern.hostuuid sysctl to uniquely identify
devices. Link: 284813e

• An issue in wazuh-modulesd has been fixed that caused a SIGSEGV while
decompressing the vulnerability detection database and accesses to an
unitialized structure. Link: d3c13b6

• An issue in the agent has been fixed that caused a "permission error" due
to an incorrect owner in the etc/clients.keys file. Link: c74ab75

• security/wazuh-server switched from beats7 to beats8. Link: ce6831e

• Fixed a segmentation fault in wazuh-modulesd when pkg(8) is not installed
on the system and sysinfo’s getPackages() function is trying to obtain
information about installed packages. Now this function has been
reimplemented to use SQLite. Link: ff95715, a4242bf

• Apply dos2unix(1) to Wazuh API’s api.yaml file. Link: a4242bf

• An issue with wazuh-apid has been fixed that prevents it to start
correctly, marking itself as DOWN, when security.bsd.see_other_{u,g}ids is
set to 0. Link: c86d3fc

• A page has been created on the FreeBSD wiki to centralize the work we have
done and what remains to be done. Link: Wiki

Makejails for Wazuh has been improved and now mimics the official Dockerfiles,
so users familiar with it can easily deploy all Wazuh components using AppJail
and Director:

• wazuh-manager

• wazuh-agent

• wazuh-indexer

• wazuh-certs-tool

• wazuh-dashboard

This also adds cluster-mode infrastructure for Makejails.

Vulnerability detection is not yet implemented in FreeBSD, but Serpico has been
developed to address this deficiency. Serpico is a security scanner for FreeBSD
packages and releases that compares versions against a list of versions marked
as vulnerable and displays vulnerability information in a compact JSON format
for easy analysis with other security tools. The package includes rules for
Wazuh and a dashboard that can be easily installed via the web-UI or the
OpenSearch Dashboards API.

Current version: 4.14.3

FreeBSD HPC Modernization Initiative: Ecosystem Expansion and Upstream
Integration

Links:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/pmix URL: https://cgit.freebsd.org/ports/tree/net/pmix/
net/prrte URL: https://cgit.freebsd.org/ports/tree/net/prrte/
net/openmpi URL: https://cgit.freebsd.org/ports/tree/net/openmpi/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
benchmarks/py-reframe-hpc URL:
https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
sysutils/mpifileutils URL:
https://cgit.freebsd.org/ports/tree/sysutils/mpifileutils/

Contact: Generic Rikka <rikka.goering@outlook.de>

This report continues the ongoing FreeBSD HPC Ports Modernization initiative,
which aims to make FreeBSD a practical and maintainable platform for modern
high-performance computing (HPC) software stacks.

Previous work focused on updating the core scheduler and runtime stack by
modernizing sysutils/slurm-wlm and introducing standalone ports for net/pmix
and net/prrte. During this quarter the focus shifted toward expanding the
surrounding HPC ecosystem, improving integration between components, and
upstreaming portability fixes discovered during the porting process.

The long-term goal is to provide a coherent HPC software environment in the
FreeBSD Ports Collection that resembles what users expect on Linux-based HPC
systems while remaining maintainable within the FreeBSD ecosystem.

Work completed

• Continued tracking upstream releases of sysutils/slurm-wlm, keeping the
FreeBSD port current with the latest upstream versions. Recent updates
confirm that Slurm can successfully schedule and execute jobs on FreeBSD
with only a minimal patchset.

• Introduced net/ucx, providing the Unified Communication X framework used by
modern MPI implementations for high-performance communication.

• Added benchmarks/py-reframe-hpc, enabling regression testing and validation
workflows commonly used on production HPC clusters.

• Continued improving interoperability between net/openmpi, net/ucx, net/pmix
, and net/prrte within the FreeBSD Ports Collection.

Work in progress

• Porting sysutils/mpifileutils and its dependency stack (devel/libcircle,
devel/lwgrp, devel/dtcmp) to provide MPI-parallel file utilities commonly
used on large HPC filesystems.

• Upstreaming portability fixes discovered during the porting process to
projects such as UCX and mpifileutils, reducing the need for
FreeBSD-specific patches.

• Ongoing collaboration with SchedMD developers to upstream improvements
discovered while maintaining Slurm on FreeBSD.

• Coordination with the OpenMPI ports maintainer to improve integration
between OpenMPI and modern networking frameworks such as UCX.

Future plans

• Continue expanding the HPC software ecosystem available in the FreeBSD
Ports Collection.

• Further reduce local patchsets by contributing portability fixes upstream
whenever possible.

• Develop documentation describing how the Slurm + OpenMPI + PMIx + PRRTE +
UCX stack can be deployed together on FreeBSD, lowering the barrier for
users who want to experiment with HPC workloads on the platform.

• Provide example configurations and integration guidance so that FreeBSD can
serve as a realistic development and testing environment for HPC software.

Improve libvirt support for bhyve hypervisor

Links:
libvirt: Bhyve driver URL: https://libvirt.org/drvbhyve.html

Contact: Roman Bogorodskiy <novel@FreeBSD.org>

Completed work

• libvirt/bhyve driver:

□ arm64 support added.

□ virtio-scsi device support added.

□ vCPU pinning configuration support added.

□ NUMA domains configuration support added.

□ Assorted minor improvements and bugfixes.

Plans for the next quarter

• Add support (targeted, but might roll over to next quarter) for:

□ Boot order configuration.

□ TPM devices.

□ Complete suspend/resume support.

□ virtio-console devices and Qemu Guest Agent.

• Improve virt-manager support on FreeBSD.

• Extend libvirt CI to test against FreeBSD-CURRENT snapshot VM images.

Sponsor: The FreeBSD Foundation