diff --git a/website/content/en/status/report-2026-04-2026-06/bhyve-cpuid.adoc b/website/content/en/status/report-2026-04-2026-06/bhyve-cpuid.adoc index 763cc9cfb8..9b4312ab9e 100644 --- a/website/content/en/status/report-2026-04-2026-06/bhyve-cpuid.adoc +++ b/website/content/en/status/report-2026-04-2026-06/bhyve-cpuid.adoc @@ -1,68 +1,68 @@ === Full CPUID Control for bhyve Contact: Hans Rosenfeld ==== 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 the bhyve configuration syntax The existing bhyve configuration file syntax was limited to assignments to configuration nodes, which parsed into tree-structured set of nvlists internally. In order to allow a more flexible configuration using pre-defined configuration file snippets, the bhyve configuration file syntax has been augmented with two new features: - A configuration node can be appended to with the `+=` operator. If a value has already been assigned to the same configuration node, the new value is appended to the old value, separated by a comma. - Another configuration file can be included with an `include` directive. Absolute and relative paths are supported, but relative paths are understood as relative to the path of the configuration file the include directive appears in. ===== Yet more flexible CPUID configuration The CPUID configuration mechanism has been extended to support symbolic feature names, where each name corresponds to a particular bit of a register for a CPUID function. This is particularly useful for individual instruction set extensions or other optional features that can be turned off or on at will. So instead of configuring `cpuid.0x00000001+=edx|=0x00040000`, you can now simply write `cpuid.enable+=psn`. There is also a corresponding option `cpuid.disable` for symbolic features. Using bit manipulation on CPUID register is of course still supported as not all CPUID features can be expressed in terms of individual feature bits. ===== Using x86 architecture levels The x86 architecture levels are now implemented as a set of pre-defined configuration file snippets, each higher level building on top of the lower level. To illustrate this, here's what x86-64-v3.cfg looks now: ------------------- include x86-64-v2.cfg cpuid.enable+=fma,movbe,osxsave,avx,f16c cpuid.enable+=bmi1,avx2,bmi2 cpuid.enable+=abm ------------------- The CPU or architecture model can be selected either by including the corresponding configuration file from `/usr/share/bhyve/cpu` in the bhyve configuration file, or it can be specified on the command line as part of the vCPU configuration: `bhyve [...] -c 16,model=x86-64-v1 [...]` ===== CPUID constraints -In order to prevent accidentally enabling CPUID features for a guest CPU which the host CPU doesn't support, the CPUID configuration parser has been extended with a list of CPUID constraints, which are consulted when a particular CPUID register value is set or modified. +In order to prevent accidentally enabling CPUID features for a guest CPU which the host CPU does not support, the CPUID configuration parser has been extended with a list of CPUID constraints, which are consulted when a particular CPUID register value is set or modified. For any register in a CPUID function, a constraint can specify which bits are immutable and which may be cleared only. The constraints are checked after the CPUID configuration has been applied. ==== Plans for next quarter * Implement overrides for CPUID constraints to ignore any constraints or to warn about violation of a constraint instead of failing VM setup. * Provide more pre-defined CPU configurations based on real-world CPUs. * 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 diff --git a/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc b/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc index 3e0d719861..b4a31158d0 100644 --- a/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc +++ b/website/content/en/status/report-2026-04-2026-06/bluetooth.adoc @@ -1,39 +1,39 @@ === Bluetooth HID drivers Links: link:https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices[FreeBSD wiki project page] URL: link:https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices[] + -link:https://github.com/majintosh/freebsd-bthid[Project Github repo] URL: link:https://github.com/majintosh/freebsd-bthid[] +link:https://github.com/majintosh/freebsd-bthid[Project GitHub repo] URL: link:https://github.com/majintosh/freebsd-bthid[] Contact: Majed Alkhaleefah I have been working on two drivers to enable support for HID drivers for Bluetooth devices as part of GSoC 2026. The primary goal of this project is to register connected Bluetooth HID devices as Newbus devices via two new drivers: `bthidbus` and `bthid`. `bthidbus` acts as the parent bus that manages the creation and attachment of `bthid` child devices. `bthid` serves as the transport layer, spawning a `hidbus` device and routing all received packets to it once they are stripped of their headers. The short-term goal here is to enable support for wireless HID connections. The longer-term goal is to begin setting the foundation that allows others to write drivers for devices that can only connect via Bluetooth. What has been accomplished: * `bthidbus` can successfully open a connection to a Bluetooth device via sockets. * `bthid` can receive and manage sockets handed down from `bthidbus` via ivars. * `bthid` can send the report descriptor to `hidbus`, which successfully spawns the correct HID device and driver. (e.g., a gamepad connected over Bluetooth spawns an `hgame` device and an `evdev` node.) * Input from Bluetooth devices is successfully received by `hidbus` and `evdev`. Current issues and planned changes: * The actual report descriptors, Bluetooth addresses, etc, have to be hardcoded into `bthidbus`. I initially considered adding the querying/listening logic to `bthidbus` to make it act like a pseudo-server, but I worried this would risk bloating and scope creep. The approach I will be going with instead is to rely on the `bthidd` daemon's existing querying logic and have it send new connection information to `bthidbus` via an `ioctl`. This would remove `bthidbus` 's current role as the connection-initiator and instead have it only manage connections that have already been opened. * There is significant input latency when monitoring via `evtest`. I have two different working hypotheses. The first is that the issue lies in `bthid` and how it manages interrupts via taskqueues. The second is that it lies in the Networking stack, as Bluetooth packets are piped between multiple different Netgraph nodes before being received by `bthid`. This could also very well be an issue with `evtest`; I still have to look into this. All testing so far has been done with the Nintendo Switch Pro Controller. diff --git a/website/content/en/status/report-2026-04-2026-06/dockerbox.adoc b/website/content/en/status/report-2026-04-2026-06/dockerbox.adoc index f9bdc1ba12..7f40f56b80 100644 --- a/website/content/en/status/report-2026-04-2026-06/dockerbox.adoc +++ b/website/content/en/status/report-2026-04-2026-06/dockerbox.adoc @@ -1,44 +1,44 @@ === Dockerbox Links: + -link:https://github.com/leafoliage/freebsd-dockerbox[freebsd-dockerbox Github] URL: link:https://github.com/leafoliage/freebsd-dockerbox[] + -link:https://github.com/leafoliage/dockerbox-broker[dockerbox-broker Github] URL: link:https://github.com/leafoliage/dockerbox-broker[] + -link:https://github.com/leafoliage/freebsd-dockerbox-debian[freebsd-dockerbox-debian Github] URL: link:https://github.com/leafoliage/freebsd-dockerbox-debian[] +link:https://github.com/leafoliage/freebsd-dockerbox[freebsd-dockerbox GitHub] URL: link:https://github.com/leafoliage/freebsd-dockerbox[] + +link:https://github.com/leafoliage/dockerbox-broker[dockerbox-broker GitHub] URL: link:https://github.com/leafoliage/dockerbox-broker[] + +link:https://github.com/leafoliage/freebsd-dockerbox-debian[freebsd-dockerbox-debian GitHub] URL: link:https://github.com/leafoliage/freebsd-dockerbox-debian[] Contact: Chun-Cheng Yeh Dockerbox is a virtualized Docker daemon. Although the Docker daemon is not natively available on FreeBSD, Dockerbox runs it inside a Debian Bhyve virtual machine to provide access to it. Dockerbox supports common Docker features such as Docker Compose, port publishing, and bind mounts. This project aims to facilitate non-production Docker usage on FreeBSD. ==== Related Ports and Repositories * link:https://github.com/leafoliage/freebsd-dockerbox[freebsd-dockerbox] + Provides Docker on FreeBSD by running `dockerd` inside a Linux Bhyve VM. This service manages the lifecycle of the Dockerbox guest, along with its network and storage settings. + *v0.2.5 — ported.* * link:https://github.com/leafoliage/dockerbox-broker[dockerbox-broker] + A child service of Dockerbox that handles port forwarding from the host to the Dockerbox guest when a container requests port publishing. + *Not yet ported.* * link:https://github.com/leafoliage/freebsd-dockerbox-debian[freebsd-dockerbox-debian] + Codebase used to generate Dockerbox's disk image. + *Not ported.* * link:https://www.freshports.org/sysutils/docker-cli/[docker-cli] + The Docker CLI tool. + *v29.4.2 — ported.* * link:https://www.freshports.org/sysutils/docker-compose/[docker-compose] + A Docker CLI plugin for defining and running multi-container applications. + *v5.1.3 — ported.* * link:https://www.freshports.org/sysutils/docker-buildx[docker-buildx] + A Docker CLI plugin providing extended build capabilities via BuildKit. + *v0.34.1 — ported.* package:sysutils/dockerbox[], package:sysutlis/docker-cli[], package:sysutils/docker-compose[], and package:sysutils/docker-buildx[] are now available in the FreeBSD Ports Collection and via `pkg`. Sponsor: The FreeBSD Foundation diff --git a/website/content/en/status/report-2026-04-2026-06/hpc-ports-modernization.adoc b/website/content/en/status/report-2026-04-2026-06/hpc-ports-modernization.adoc index 907f41eb7a..adb0198f3f 100644 --- a/website/content/en/status/report-2026-04-2026-06/hpc-ports-modernization.adoc +++ b/website/content/en/status/report-2026-04-2026-06/hpc-ports-modernization.adoc @@ -1,46 +1,47 @@ === FreeBSD HPC Ports Modernization: Slurm 26.05, UCX 1.20 Upstreaming, and MPI-Parallel File Utilities Links: + link:https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/[sysutils/slurm-wlm] URL: link:https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/[] + link:https://cgit.freebsd.org/ports/tree/net/ucx/[net/ucx] URL: link:https://cgit.freebsd.org/ports/tree/net/ucx/[] + link:https://cgit.freebsd.org/ports/tree/sysutils/mpifileutils/[sysutils/mpifileutils] URL: link:https://cgit.freebsd.org/ports/tree/sysutils/mpifileutils/[] + link:https://cgit.freebsd.org/ports/tree/devel/libcircle/[devel/libcircle] URL: link:https://cgit.freebsd.org/ports/tree/devel/libcircle/[] + link:https://cgit.freebsd.org/ports/tree/devel/lwgrp/[devel/lwgrp] URL: link:https://cgit.freebsd.org/ports/tree/devel/lwgrp/[] + link:https://cgit.freebsd.org/ports/tree/devel/dtcmp/[devel/dtcmp] URL: link:https://cgit.freebsd.org/ports/tree/devel/dtcmp/[] + link:https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/[benchmarks/py-reframe-hpc] URL: link:https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/[] + link:https://github.com/openucx/ucx/pull/11354[openucx/ucx#11354: UCS/TYPE portability fixes for non-glibc/Clang environments (merged)] URL: link:https://github.com/openucx/ucx/pull/11354[] + link:https://github.com/openucx/ucx/pull/11549[openucx/ucx#11549: UCS/SYS portability fixes for non-Linux platforms (in review)] URL: link:https://github.com/openucx/ucx/pull/11549[] + link:https://github.com/hpc/mpifileutils/pull/664[hpc/mpifileutils#664: Portability fixes for FreeBSD/non-Linux builds (in review)] URL: link:https://github.com/hpc/mpifileutils/pull/664[] + link:https://kavocado.net/reports/[Kavocado Monthly Status Reports – FreeBSD HPC notes] URL: link:https://kavocado.net/reports/[] Contact: Generic Rikka This report continues the FreeBSD HPC Ports Modernization initiative. Previous quarters focused on bringing the Slurm + PMIx + PRRTE + UCX stack up to date and filling gaps in the surrounding ecosystem. This quarter's work centered on three things: keeping the core scheduler and communication libraries current against fast-moving upstream releases, upstreaming the FreeBSD portability fixes accumulated while maintaining these ports so the local patchsets keep shrinking, and adding a new port for MPI-parallel file utilities that are common on large HPC filesystems. ==== Work completed * Updated package:sysutils/slurm-wlm[] twice this quarter, from 25.11.4 to 25.11.5 and then from 25.11.5 to 26.05.1, tracking the latest upstream releases. * Fixed several FreeBSD-specific runtime issues in package:net/ucx[]: hardened async thread state handling, corrected UCM relocation handling, fixed mm signal socket binding, and resolved other FreeBSD runtime portability issues. * Updated package:net/ucx[] from 1.20.0 to 1.20.1, and separately fixed a libucm early-init panic together with several gtest suite failures uncovered while validating the update. -* Added package:sysutils/mpifileutils[] as a new port, along with its dependency stack: package:devel/libcircle[], package:devel/lwgrp[], and package:devel/dtcmp[]. These provide MPI-parallel file utilities (copy, remove, checksum, etc.) commonly used on large HPC filesystems. +* Added package:sysutils/mpifileutils[] as a new port, along with its dependency stack: package:devel/libcircle[], package:devel/lwgrp[], and package:devel/dtcmp[]. + These provide MPI-parallel file utilities (copy, remove, checksum, etc.) commonly used on large HPC filesystems. * Updated package:benchmarks/py-reframe-hpc[] twice this quarter to track upstream releases of the regression testing framework. * Upstreamed "UCS/TYPE: Portability fixes for non-glibc/Clang environments" to UCX, which was reviewed and merged. * Opened "UCS/SYS: portability fixes for non-Linux platforms" against UCX, covering hostname buffer sizing, MAC address retrieval via `getifaddrs()`/`AF_LINK`, shared-memory error reporting, `mmap`/`munmap`-based reallocation, and `cpuset_getaffinity()`-based thread affinity queries; currently addressing review feedback. * Opened a portability PR against mpifileutils guarding Linux-only APIs for FreeBSD and other non-Linux builds; currently in review. * Collaborated with SchedMD on a Slurm configure-time probe for `H5PTopen`, used to detect the HDF5 high-level library, which was merged upstream. ==== Work in progress * Addressing reviewer feedback on the open UCX and mpifileutils portability pull requests to get them merged upstream and reduce the FreeBSD ports' local patchsets further. * Continuing collaboration with SchedMD to upstream additional portability fixes discovered while maintaining package:sysutils/slurm-wlm[] on FreeBSD, including BSD socket-handling improvements. * Evaluating a `proctrack/freebsd_reaper` Slurm plugin design, made possible by recently landed FreeBSD kernel support for exposing reaper metadata in process information. * Continuing to track upstream Slurm, UCX, and PMIx/PRRTE releases closely to keep the FreeBSD ports current with minimal local patching. ==== Future plans * Land the outstanding UCX and mpifileutils upstream pull requests, and continue identifying further portability issues to upstream rather than patch locally. * Prototype and submit the Slurm `proctrack/freebsd_reaper` plugin once the underlying kernel interface work is finalized. * Continue expanding the HPC software ecosystem available in the FreeBSD Ports Collection and reduce local patchsets across the stack wherever upstream acceptance is possible. * Document a reference Slurm + OpenMPI + PMIx + PRRTE + UCX deployment on FreeBSD to lower the barrier for new sites experimenting with FreeBSD in an HPC context. diff --git a/website/content/en/status/report-2026-04-2026-06/openjdk.adoc b/website/content/en/status/report-2026-04-2026-06/openjdk.adoc index 77ee433995..54321f7c76 100644 --- a/website/content/en/status/report-2026-04-2026-06/openjdk.adoc +++ b/website/content/en/status/report-2026-04-2026-06/openjdk.adoc @@ -1,61 +1,61 @@ === Improve OpenJDK on FreeBSD Links: + link:https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/[Project description] URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/[] + link:https://github.com/freebsd/openjdk[Project repository] URL: https://github.com/freebsd/openjdk[] + link:https://github.com/openjdk/bsd-port[Upstream BSD port repo] URL: https://github.com/openjdk/bsd-port[] Contact: + Harald Eilertsen + FreeBSD Java mailing list 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. This quarter has been spent mostly on getting the upstreaming process properly going. -We submit patches to a link:https://github.com/openjdk/bsd-port[separate repository] under the OpenJDK org on Github, and make sure that each PR is reviewed by at least one upstream reviewer. +We submit patches to a link:https://github.com/openjdk/bsd-port[separate repository] under the OpenJDK org on GitHub, and make sure that each PR is reviewed by at least one upstream reviewer. This way, when we get to the point where we want to merge our port into the upstream mainline, all commits should already be reviewed by someone in the project. This is a fairly slow process, as we depend on upstream reviewers having time. We also encounter that some of the changes that has been living in our port for a long time is rejected. Then we have to rework them, or if not strictly needed, just throw them out. I feel this is a useful correction, but sometimes causes quite a bit of work. In this quarter the following issues/milestones were reached: * OpenJDK 25 port was updated to link:https://reviews.freebsd.org/D56522[version 25.0.3]. * Upstream mainline changes and bugfixes: - link:https://github.com/openjdk/jdk/pull/30853[8382614: Consolidate implementation of current_stack_base_and_size on BSD] - link:https://github.com/openjdk/jdk/pull/31069[8384085: Make os::Bsd::dlopen_helper private, and drop unused arg] - link:https://github.com/openjdk/jdk/pull/31070[8384088: osThread _thread_id should be an int on all BSD's] - link:https://github.com/openjdk/jdk/pull/31199[8384946: os::Bsd::gettid misses the return value] - link:https://github.com/openjdk/jdk/pull/31455[8386344: runtime/StackGuardPages/TestStackGuardPages build failure after JDK-8303612] * Upstream BSD Port: - link:https://github.com/openjdk/bsd-port/pull/7[Fix conditional sections for BSD in hotspot/cpu] - link:https://github.com/openjdk/bsd-port/pull/8[Port hotspot/os/posix for BSD] - Merged changes accepted for mainline. * Current (out-of-tree) BSD port: - link:https://github.com/battleblow/jdk/pull/49[Merge + Remove VFORK for BSD + rebase GHA workflow on OpenJDK26] - link:https://github.com/battleblow/jdk/pull/53[Merge + Fix usage of FREE_C_HEAP_ARRAY macro on BSD] - link:https://github.com/battleblow/jdk/pull/54[Sync aarch64 cpuinfo impl for *BSD with Linux] - link:https://github.com/battleblow/jdk/pull/55[Remove duplicate include in global defs for zero] - link:https://github.com/battleblow/jdk/pull/59[Remove ThreadWXEnable from BSD code] - Backported changes accepted for mainline upstream BSD port. * Ports: - link:https://cgit.freebsd.org/ports/commit/?id=7878106082fd1f07814d754ef767c1f59168d1e9[java/javavmwrapper: JAVA_VERSION does not work with openjdk25] In addition, these tasks are still ongoing, or waiting for review: * Upstream BSD port: - link:https://github.com/openjdk/bsd-port/pull/9[Port hotspot/os/bsd/os_perf_bsd.cpp to BSD] (Waiting for refactor, see link:https://github.com/battleblow/jdk/pull/61[WIP: Split os_perf impl for macOS and BSD]) - link:https://github.com/openjdk/bsd-port/pull/11[os::get_process_uid and os::rss for BSD] (Still ongoing) Other notes: * Started preparing for link:https://github.com/snake66/jdk/tree/freebsd-jdk27[OpenJDK 27 port]. * Presented the project at link:https://foss-north.se/2026/speakers-and-talks.html#heilertsen[Foss North 2026]. Sponsor: The FreeBSD Foundation diff --git a/website/content/en/status/report-2026-04-2026-06/rocm.adoc b/website/content/en/status/report-2026-04-2026-06/rocm.adoc index f6f763cb8e..8374e6cb09 100644 --- a/website/content/en/status/report-2026-04-2026-06/rocm.adoc +++ b/website/content/en/status/report-2026-04-2026-06/rocm.adoc @@ -1,25 +1,26 @@ === ROCm support on FreeBSD Links: + link:https://github.com/Yohello1/drm-kmod-rocm/tree/super-special[drm-kmod fork with partial amdkfd support] URL: link:https://github.com/Yohello1/drm-kmod-rocm/tree/super-special[] + link:https://github.com/Yohello1/rocm-systems[rocm-systems fork with fixes for FreeBSD] URL: link:github.com/Yohello1/rocm-systems[] + Contact: Sourojeet Adhikari -ROCm is the compute platform used by AMD for their GPUs. As of now, FreeBSD does not support ROCm at all, neither at the toolchain level nor at the driver level. +ROCm is the compute platform used by AMD for their GPUs. +As of now, FreeBSD does not support ROCm at all, neither at the toolchain level nor at the driver level. I am working to change that and upstream the required changes. To my knowledge, on FreeBSD there are a few ways to run compute loads (like AI/ML, graphics, etc) on the GPU; those ways, to my knowledge, are Vulkan and OpenGL. Both Vulkan and OpenGL are fairly good for compute workloads, namely in graphics and sometimes machine learning loads too. But sometimes there are tasks which are not well-suited for Vulkan and OpenGL, and are instead done in ROCm/CUDA because ROCm and CUDA give the developer a lot more control over how the task is done. So I am trying to introduce ROCm support to FreeBSD so we can run ROCm code/programs on FreeBSD. There are a few things we need working to get ROCm working. The first is AMD's LLVM fork, which I have patched, gotten working, and have upstreamed the patches. Next are the ROCm runtimes, which have been patched, and I am currently working on upstreaming the patches. Finally is the amdkfd driver, which I am working on patching, and am upstreaming some of the LinuxKPI-related patches back to the FreeBSD kernel. As of late, I have upstreamed changes to AMD's LLVM fork allowing the compilation of their fork on FreeBSD so you can build their ROCm toolchain. Beyond that, I have worked on getting a series of patches into LinuxKPI to slowly bring in amdkfd support. Sponsor: The FreeBSD Foundation