[continued from previous message]

• More virtual_oss patches and improvements.

• Attempt to implement an snd_hda(4) pin-patching mechanism.

• Investigate SOF/DMIC support.

You can also follow the development process in freebsd-multimedia@, where I post regular reports.

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 by the base system and some installed from ports/packages. The main goal is to be a desktop application focus on desktop user to easily and quickly setup and run virtual machines on FreeBSD hosts.

It should be used for virtual machines testing purpose (not for production). For a tool for production virtual machines management, take a look at sysutils/ vm-bhyve, sysutils/bmd, or sysutils/cbsd.

Bhyvemgr supports aarch64 on 15-CURRENT only, and amd64 from FreeBSD 13.x to 15-CURRENT. It can be compiled from sysutils/bhyvemgr as a port, or installed as packages with gtk2, qt5, or qt6 interface support.

People interested in helping the project are welcome.

Version at the end of 2024Q3: 1.1.0

TODO

• Test on real aarch64 hardware

• Add uart device support

• Add missing global setting entries (bios, board, chassis, system)

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

Changes to dhclient to speed up the FreeBSD boot process

Links:
Speeding up the FreeBSD boot process URL: https://wiki.freebsd.org/SummerOfCode2024Projects/SpeedingUpTheFreeBSDBootProcess

dhclient Pull Request URL: https://github.com/freebsd/freebsd-src/pull/1368

Contact: Isaac Cilia Attard <icattard@FreeBSD.org>

As part of my Google Summer of Code 2024 project, involving speeding up the FreeBSD boot process, I have worked on decreasing the time it takes for ARP resolution within dhclient to happen. This involved reducing the default ARP resolution timeout from 2000 ms to 250 ms, and adding an option to disable it altogether. The latter is useful within cloud environments, where a node is certain to have an IP address allotted to it.

As a consequence of this, connecting to a DHCP network is now faster, including the boot process during which this happens. The speedup experienced is about 2 seconds.

This causes FreeBSD systems to boot significantly faster than before.

Sponsor: Google LLC (GSoC 2024)

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

Capsicum and Bhyve Code Audit

Contact: Ed Maste <emaste@FreeBSD.org> Contact: Pierre Pronchery < pierre@freebsdfoundation.org>

With the support of the Alpha-Omega project, the FreeBSD Foundation undertook code audits of two important subsystems — the bhyve hypervisor, and the Capsicum sandboxing framework. In addition to uncovering vulnerabilities in these systems to correct, the audits look to identify classes of vulnerabilities and/or suboptimal coding practices that we can look to address across the project.

The Foundation interviewed several firms, and selected Synacktiv to perform the audit. A number of issues with critical and high severity were identified, which have been fixed as documented in security advisories:

• FreeBSD-SA-24:09.libnv

• FreeBSD-SA-24:10.bhyve

• FreeBSD-SA-24:11.ctl

• FreeBSD-SA-24:12.bhyve

• FreeBSD-SA-24:14.umtx

• FreeBSD-SA-24:15.bhyve

• FreeBSD-SA-24:16.libnv

Fixes are in progress for a number of lower-severity issues. The code audit report will be shared in the near future, after issues above a severity threshold have been addressed. The FreeBSD Foundation will also publish a report including commentary on the impact of the Synacktiv code audit report, classes of vulnerabilities identified, and lessons learned.

More information is available in the Alpha-Omega repository.

Sponsor: The FreeBSD Foundation

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

Endpoint-Independent NAT

Contact: Tom Jones <thj@freebsd.org>

This project aims to add support for Endpoint-Independent Mappings for UDP to the pf and ipfw firewalls.

End Point Independent NAT enables applications behind a NAT speaking to multiple remote hosts to receive the same mappings. This allows an application without any NAT traversal mechanisms to work around NAT issues to perform peer discovery. From the remote hosts perspective the NAT is transparent and it is as-if there is no NAT at all. This form of NAT has been given several names over the last few decades and might be known as 'full-cone' NAT.

Patches to pf landed in early September based on work by Damjan Jovanovic and Naman Sood with updates to work on pf in main. The patches add a new 'endpoint-independent' suffix to UDP pf nat rules.

ipfw support for endpoint-independent is going to be made available via libalias, allowing any system which uses libalias for address translation to benefit from the change. There is an in-progress review D46689 to add support to libalias.

The in-progress change and the committed pf change could both benefit from testing in more and diverse environments.

Sponsor: The FreeBSD Foundation Sponsor: Tailscale

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

Kyua Jail Support

Contact: Igor Ostapenko <igoro@FreeBSD.org>

The FreeBSD test suite is executed by the kyua(1) utility. Kyua supports parallel execution of tests with kyua -v parallelism=<n> test, however many network tests leverage jail(8) features like VNET(9) and have conflicts with jail naming and network configuration. As a result they are marked with the is_exclusive=true metadata property to prevent them from running at the same time and interfering with each other. It creates a dilemma when a project aims to increase test coverage, but the accumulation of exclusive tests proportionally increases the time required to run them. This, in turn, affects the development process from multiple angles.

Kyua has recently got a change in 15-CURRENT to support a new concept called "execution environment". By default, tests run in the so-called "host" execution environment, where they are executed as before. A test can opt-in to use a brand new execution environment, the "jail" one. In this case, kyua creates a jail before running the test, and then executes the test within the jail. That opens up the opportunity to run more tests in parallel due to the extra isolation provided by the jail concept itself, and specifically by the VNET. It depends on hardware and configuration, but there are reports that having the same environment netpfil/pf tests can be run around 4 times faster — a few minutes instead of half an hour.

The following Makefile change is a quick demo of how netpfil/pf tests were switched to run in parallel with jail execution environment:

-# Tests reuse jail names and so cannot run in parallel.
-TEST_METADATA+= is_exclusive=true
+# Allow tests to run in parallel in their own jails
+TEST_METADATA+= execenv="jail"
+TEST_METADATA+= execenv_jail_params="vnet allow.raw_sockets"

More details:

• The key commit with detailed description:
257e70f1d5ee61037c8c59b116538d3b6b1427a2

• The man pages covering the "execenv" feature: kyuafile(5), kyua.conf(5)

This change also brings new sysctl read-only variables, which expose more details about current jail, and may be generally useful:

• security.jail.children.max: Maximum number of child jails

• security.jail.children.cur: Current number of child jails

A hint: the sysctl -n security.jail.children.cur run from prison0 provides the number of all jails in the system.

Further improvements to Kyua, such as requirements definition and automatic resolution, are currently in the design phase. Potentially new metadata properties like required_klds and required_pkgs provide a clue to these topics. Please contact Igor to discuss ideas and use cases that can help shape these upcoming Kyua enhancements.

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

Linux Source Compatibility Wiki page

Links:
Linux Source Compatibility URL: https://wiki.freebsd.org/LinuxSourceCompatibility

Contact: Edward Tomasz Napierala <trasz@freebsd.org>

There is now a wiki page to track source compatibility differences between FreeBSD and Linux — and it needs your input!

FreeBSD and Linux are already largely compatible at the source code level due to both being Unix systems and following the same standards. There are however certain system calls specific to Linux; there are also differences in header files, constants and so on. Implementing them in FreeBSD would make porting software easier.

Not all of the items there are fixable. Some differences cannot be eliminated due to naming clashes, disagreements on how the system is supposed to work, or because it would make autoconf pick up a less functional compatibility API instead of the native one. In such cases we should document it and advise what API to use instead.

The wiki page aims to provide an overview and help track progress. That is where your help is needed. I need people who actually port software to FreeBSD to add missing APIs, based on their experiences. This also includes non-syscall items, like missing headers and unsupported constants. Preferably also mention the name of the software that could use them.

• Add missing items

• Add prospective API consumers

Sponsor: Innovate UK

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

Userland

Changes affecting the base system and programs in it.

Service jails — Automatic jailing of rc.d services

Links:
rc-article part for Service Jails URL: https://docs.freebsd.org/en/articles/rc-scripting/#rcng-service-jails
service jail patches for ports in our bugtracker URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=service+jail+aware

Contact: Alexander Leidinger <netchild@FreeBSD.org>

Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional
configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)).

Since the last report several ports have been modified to come with a service jail config. Out of about 1460 start scripts in the ports collection, about 80 start scripts are changed. Prominent examples out of those are postgresql, DNS servers, FTP servers, PHP, dovecot, postfix, rspamd, amavisd-new and clamav. Some more changes are waiting for a treatment by the corresponding port maintainers.

Any help in changing more start scripts (most of the time just one line to add) is welcome. If you want to help, you can check the bugtracker link above for changes which are already under review.

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

Userspace UFS Driver (fuse-ufs)

Links
fuse-ufs GitHub URL: https://github.com/realchonk/fuse-ufs

Contact: Benjamin Stürz <benni@stuerz.xyz>

During this year’s Summer of Code, I wrote a userspace UFS driver using FUSE and Rust. The project was meant to ease the process of mounting FreeBSD UFS filesystems on other operating systems. Up to this point, only read-only filesystem access has been implemented. But as a bonus, fuse-ufs has the ability to mount filesystems with endianness different from the host’s endianness.

I am currently working on splitting the project into a binary and library part, to make it easier to integrate it into other operating systems. As part of this refactoring, an additional FUSE2 backend will be implemented, to be able to run it on OpenBSD. Currently there is testing infrastructure for Linux and FreeBSD with OpenBSD coming in the future. Although there is no CI for MacOS, a friend of mine tested it with MacFUSE and it works.

Once the big refactor is done, I will start concentrating on implementing write support. Thanks to being bribed by Robert Clausecker, I will also add soft-updates and mounting Sun’s UFS in the future.

The driver can be installed using cargo install fuse-ufs, or (if on Arch Linux) using your favorite AUR helper. Thanks to Robert Clausecker a port for FreeBSD exists in sysutils/fusefs-ufs.

A big thanks to Alan Somers and Kirk McKusick for mentoring me and thanks to Robert Clausecker for the FreeBSD port and suggesting this GSoC project to me in the first place. Another thanks to Davids Paskevics for writing a fuzzer for me.

Sponsor: Google Summer of Code 2024

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

Kernel

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

FreeBSD V4L2 & kernel USB Video Class driver

Links:
Public development repository URL: https://github.com/AlvinChen1028/freebsd-src/tree/feature-uvc
Upstreaming preparation repository URL: https://github.com/lwhsu/freebsd-src/pull/2

Contact: Alvin Chen <weike_chen@dell.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

This work is to create FreeBSD UVC (USB Video Class) kernel driver and follow v4l2 APIs, so that most of the Linux camera applications can be easily ported to FreeBSD.

The code is still cleaning up and will be submitted to official review after completing.

Current Status:

1. The key functions of the UVC driver are enabled.

2. The key v4l2 IOCTLs are implemented.

3. Support most of USB cameras (up to 4K resolution): Jabra, Logitech, etc.

4. Some applications validated: VLC, Cheese, pwcview.

Future Work:

1. A couple of v4l2 IOCTLs need be implemented: make all cases in
v4l2-compliance test suite be passed.

2. Some UVC APIs need be implemented: uvc control mapping callbacks, etc.

3. UVC lock issue related to USB.

4. PCI based AI camera supporting.

5. Code refactoring if needed.

Sponsor: Dell Technologies for the development
Sponsor: The FreeBSD Foundation for assistance of upstreaming

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

mac_do(4), setcred(2), mdo(1)

Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr> Contact: Baptiste Daroussin <bapt@FreeBSD.org>

This project aims at allowing controlled process credentials transitions without using setuid executables but instead leveraging our MAC framework.

Traditional programs for credentials change have to execute preliminary operations as root (if not as the effective UID, at a minimum as the saved UID). Some of these programs (e.g., sudo(8)) have lots of lines of codes and comprise features (e.g., loadable security modules) that can be dangerous from a security standpoint. Thus, they have a non-negligible attack surface and are difficult to prove correct. Additionally, in most scenarios, the extra features they bring are not necessary.

More generally, the threat model for the mac_do(4) kernel module part is that of compromised userland programs, be they credentials changers or credentials providers ones. This stance implies that calls to the kernel’s credentials-changing API must be monitored by the kernel without upcalls to userland. In practice, mac_do(4) must be configured beforehand by the administrator to indicate which transitions of credentials are valid (through a sysctl(8) knob, security.mac.do.rules).

Currently, the companion userland program, mdo(1), is the only one that can be authorized to proceed by mac_do(4) (for now, based on the executable path). This tiny program simply establishes the new credentials via calls to setuid(2) , and optionally initgroups(3) (calling setgroups(2)) and setgid(2) (if -i was not passed).

The resulting set of groups is either that of the target UID based on the password database, or that before the change in UID (when using -i). The second alternative can be a security hazard in some cases (as the effective GID is not changed either), whereas the first contradicts the threat model above. The current mac_do(4) rules specification indeed only allows to express simple UID transitions towards explicit UIDs from other explicit UIDs or GIDs, without taking into account groups. Consequently, the kernel module currently cannot check the content of setgroups(2) and setgid(2) system calls' parameters, relying completely on mdo(1) passing the right information.

A new version of mac_do(4) has been in the works for approximately a month. Besides fixing concurrency, per-jail settings and MAC policies composition problems, it features a revamp of the rules specification in order to make it possible to finely control which groups are allowed in the resulting credentials. Notably, primary and secondary groups can now be specified independently, and for the latter, GIDs can be tagged as allowed, mandatory or forbidden. A special alias, ., can be used to indicate the current process' UIDs or GIDs depending on the context.

These new features imply that the mac_do(4) module is able to apply credentials change at once, since the allowed final credentials depend on the initial ones through the configured rules. The traditional userland interface (e.g., setuid (2), setuid(2), setgroups(2), etc.) is at odds with this requirement as it necessitates multiple calls to reach the desired final credentials, making the process pass by several successive states that themselves may not be allowed by mac_do(4)'s rules. We overcome this limitation by introducing a new system call, setcred(2), which allows to request arbitrary transitions of credentials at once. Beside its usefulness in conjunction with mac_do(4), it has the benefit of simplifying coding of credentials change in userland. Since it is also extensible, it may have the potential to be adopted later by other systems.

Pre-requisite changes are currently under review (see in particular revisions D46886 to D46889 and D46896 to D46923). The bulk of changes in mac_do(4)/mdo(1) proper will soon be pushed under review as well. An older version of the full series can be seen on GitHub.

Sponsor: The FreeBSD Foundation

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

Scheduling Priorities: 256-queue Runqueues Sub-Project

Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr>

The goal of the 256-queue runqueues sub-project is to fix FreeBSD’s POSIX compliance in that different priority levels in the SCHED_FIFO or SCHED_RR scheduling classes must lead to immediate preemption by threads having higher priority. It is part of the bigger scheduling priorities revamp project aiming at rationalizing FreeBSD scheduling interfaces, including having consistent rtprio(2) and POSIX interface behaviors (where it makes sense), enhancing POSIX compliance, removing duplicate code and fixing existing bugs, and enhancing the non-standard parts both for better control and security. Expected benefits are increased usage of FreeBSD as a soft real-time platform, e.g., for video and audio processing in casual desktop uses to professional settings. Readers interested in this topic are invited to consult AsiaBSDCon 2024’s paper and EuroBSDCon 2024’s slides for a wider view, and to contact me for questions, feedbacks or discussions.

Currently, priority levels specified either through the prio field of struct rtprio (rtprio(2) interface) or the sched_priority one of struct sched_param, for real-time scheduling classes (RTP_PRIO_FIFO and RTP_PRIO_REALTIME for the former, SCHED_FIFO and SCHED_RR for the latter) as well as idle-time ones (RTP_PRIO_IDLE), are conflated as follows: Each priority level that has the same quotient when divided by 4 is internally treated the same. In particular, threads being in the same such equivalence class but having higher priority will not preempt other threads in the same class, violating POSIX expectations for SCHED_FIFO and SCHED_RR.

To remedy this situation, we have chosen an impacting internal change on the number of queues per runqueue, and defer to the above-mentioned EuroBSDCon 2024’s slides for more details.

The switch to 256-queue runqueues having non-trivial impacts on the ULE scheduler, we have been analyzing it and tuning the scheduler to preserve its previous behavior with respect to anti-starvation and the effect of nice values. With the goal to perform further testing, we have revived Jeff Roberson’s initial ULE’s test tool, called late (currently available on GitHub
).

All the modifications made as part of this sub-project are currently under review, starting with Phabricator’s review D45387 (click on the "Stack" tab to
see the full series of reviews).

In the course of this project, we have noticed that the effect of nice values is especially weak, and consequently have produced experimental patches to make their effect stronger. However, it is not clear at this point whether we can increase their effect satisfactorily enough in the current ULE setting.

We have also started another scheduler project about adapting ULE to hybrid architectures, which might also trigger more drastic scheduler changes.

Sponsor: The FreeBSD Foundation

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

Wireless Update

Links:
Categorised Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=0

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

The ongoing wireless efforts are trying to bring more support for recent chipsets as well as newer standards.

With iwlwifi(4) and rtw88(4) being supported we received patches and initial reports for rtw89 and ath10k working for some people. Additionally ath11k, ath12k and various chipsets supported by mt76 are waiting for someone to find the time to finish compat code, test and debug.

Work is ongoing to update drivers to Linux v6.11 using the now bootstrapped vendor branches, which should help maintenance a lot in the future. One particular focus for this update is also to find ways to minimize incompatibilities between wireless compat code versions in order to support multiple Linux versions as needed.

After the native kern_malloc changes got committed, LinuxKPI is seeing ongoing work for memory allocation to play better by the rules set out in Linux which should help with DMA problems seen. There is further work pending to add missing bus_dmamap_sync() calls.

There is work to support rtw88(4) SDIO devices (being tested on an r2s-plus) and ongoing work to stabilize updated USB support which should start landing once the driver updates have finished. Lastly there are more updates in the queue to finish 11n support for LinuxKPI 802.11 compat code as well as improving native net80211 code.

If you have questions or feedback please use the freebsd-wireless mailing list. That way everyone will see, be able to join in, and the answers will be publicly archived.

Sponsor: The FreeBSD Foundation

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

VirtIO Sockets and AF_VSOCK support

Links:
Source code URL: https://github.com/daniloegea/freebsd-src/tree/virtio_vsocks

Contact: Danilo Egea Gondolfo <danilo@FreeBSD.org>

The VirtIO Socket device is used to enable communication between guests and host without networking. The AF_VSOCK protocol family enables it to be used through the sockets API.

For the past many months I have been working on a guest driver for the VirtIO Socket device and an implementation of the AF_VSOCK protocol family. Originally, I wanted to get the lxd-agent daemon working on FreeBSD but the communication with the LXD host daemon is done through VSOCKs. LXD is a nice container and virtual machine manager based on Linux/KVM and my end goal is to make FreeBSD a LXD first-class citizen.

At the moment I have it working well enough to enable the lxd-agent to work. I adapted the golang.org/x/sys library and the lxd-agent to support AF_VSOCK on FreeBSD. Features such as command execution, interactive consoles and file transfer are working.

On Linux, AF_VSOCK can be used with VirtIO, HyperV and VMware sockets as transports. I am trying to design my implementation so it will also be possible to use it with different transports in the future.

After getting the current work in a good shape, ideas for future work include integration of AF_VSOCK and HyperV Sockets (which is already supported on FreeBSD through AF_HYPERV), VIRTIO_VSOCK_F_SEQPACKET, VirtIO Socket device for bhyve and the host side of the driver.

I will continue to slowly work on this on my limited free time and hopefully have something more concrete for the next time. There is still a lot of work to be done until it become ready for code review.

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

Architectures

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

Pinephone Pro Support

Links:
Repository on Codeberg URL: https://codeberg.org/Honeyguide/freebsd-pinephonepro

Contact: Toby Kurien <toby@tobykurien.com>

A new project trying to make FreeBSD usable on the Pinephone Pro has been started during August.

The current FreeBSD RELEASE images already boot on a Pinephone Pro, but no screen output or other devices are supported. The aim is to step by step support additional components so that the device one day might be usable as a highly mobile FreeBSD device.

Over the last few weeks, the groundwork has been implemented like getting used to the device, cross-compiling and booting a 15.0-CURRENT custom kernel as well as toggling the LEDs (red/green/blue in the front). Also, the LCD backlight can be turned on already and the USB-C hub is enabled even though it is not yet functional due to missing power management support.

The next step is to write a driver for the RK818 power management chip. Without it, most of the hardware will not power on like the USB-C port above. This will be done by trying to modify the existing RK808 driver. RK818 support should then make it possible to access a lot more of the devices, e.g. allowing to enable the screen, USB peripherals or WiFi.

Additional feedback and testers are welcome.

Sponsor: Honeyguide Group

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

SIMD enhancements for aarch64

Links:
EuroBSDCon 2024 presentation URL: https://www.youtube.com/live/OzX38cWdivc?si=VsMrEmT_IdKpjv7W&t=22070
Slides from presentation (PDF) URL: http://fuz.su/~fuz/talks/eurobsdcon-str-talk.pdf
Google Summer of Code (GSoC) project description URL: https://summerofcode.withgoogle.com/programs/2024/projects/TKRS35FA
simd(7) URL: https://man.freebsd.org/cgi/man.cgi?query=simd&sektion=7&manpath=FreeBSD+15.0-CURRENT

Contact: Getz Mikalsen <getz@FreeBSD.org>

The porting effort of the SIMD enhanced libc string functions from amd64 to aarch64 has been successfully completed. There are now optimized implementations for 16 libc string functions in addition to those with implementations already available as part of the ARM optimized subroutines library. There is also a presentation regarding the general method for these methods from EuroBSDCon 2024 available on YouTube with a short description in the end of how the porting has been done with regards to the aarch64 architecture.

These enhancements significantly improve performance of string functions for all FreeBSD systems on the aarch64 platform.

The code is currently undergoing acceptance testing in the form of an exp-run building all the ports, once without and once with the patch set applied to see if it has caused any new failures.

Sponsor: Google LLC (GSoC 2024)

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

Cloud

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

FreeBSD on Microsoft HyperV and Azure

Links:
Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV

Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com> Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org> Contact: Wei Hu <whu@FreeBSD.org>
Contact: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Contact: Colin Su <yuas@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

In this quarter, we have published the 13.4-RELEASE on Azure Marketplace.

Souradeep Chakrabarti from Microsoft has added a feature to use hypercalls for TLB shootdown on Hyper-V and Azure. Micro-benchmark shows 30-40% performance improvement on TLB shootdown. This has been presented at the DevSummit 202409

Wei Hu root-caused an issue on missing CDROM device when booting FreeBSD on the latest Azure v6 VM SKU. V6 type only offers NVMe disks to guest OS. He also continues bug fixing for FreeBSD MANA NIC device.

Work in progress tasks:


[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)