According to the following article and based on using FreeBSD 14.3 on Parallels Desktop 26 on a Apple Silicon (M-series processor) myself over the past few months...FreeBSD requires two specific loader settings to avoid idle issues and excessive CPU usage after install:
https://conradresearch.com/articles/freebsd-14-on-parallels-26
In addition to what the article describes, I have also observed the VM hanging, locking up during early boot, but mainly after boot after running for long periods of time, or becoming unresponsive unless these same settings are applied. The behavior is fully reproducible on Parallels Desktop 26 running on M‑series hardware.
as documented in the referenced article (special thanks to Conrad Research LLC)
When to use these commands/workarounds
Prior to boot:
Regarding the setting: High CPU usage on FreeBSD 14.3 unless kern.hz=100 is set
With the default FreeBSD timer frequency (kern.hz=1000), Parallels Desktop 26 on Apple Silicon drives the host CPU extremely hard even when the guest is idle. Reducing the timer frequency to 100 immediately normalizes CPU usage and prevents the VM from becoming sluggish or unresponsive. This strongly suggests a timing or interrupt‑rate handling issue in Parallels’ virtualization layer when running FreeBSD 14.3 on M‑series processors.
Regarding the setting: ACPI GED causes boot hangs or interrupt storms on 14.3
FreeBSD 14.3 frequently hangs during boot or becomes stuck in an ACPI interrupt storm unless ACPI GED is disabled. By disabling GED allows the system to boot cleanly and avoids the lockups described above. This points to an incompatibility between Parallels’ ACPI GED implementation and FreeBSD’s ACPI subsystem when running on Apple Silicon.
Hopefully this helps document these in the Parallels virtualization environment for Apple M-Series processors and allows anyone to investigate further as time allows to see if a bug can be addressed down the road for FreeBSD to not need the fix in the future or maybe this is by design?
Thank you all as always!
https://conradresearch.com/articles/freebsd-14-on-parallels-26
In addition to what the article describes, I have also observed the VM hanging, locking up during early boot, but mainly after boot after running for long periods of time, or becoming unresponsive unless these same settings are applied. The behavior is fully reproducible on Parallels Desktop 26 running on M‑series hardware.
as documented in the referenced article (special thanks to Conrad Research LLC)
Code:
set kern.hz=100
set debug.acpi.disabled="ged"When to use these commands/workarounds
Prior to boot:
- Select option 3 from the boot menu to access boot loader options
- At the loader prompt
- Enter the command:
Code:
set kern.hz=100 - Enter the command:
Code:
set debug.acpi.disabled="ged" - Enter the command:
Code:
boot
Code:
echo 'kern.hz=100' | sudo tee -a /boot/loader.conf
echo 'debug.acpi.disabled="ged"' | sudo tee -a /boot/loader.confRegarding the setting: High CPU usage on FreeBSD 14.3 unless kern.hz=100 is set
With the default FreeBSD timer frequency (kern.hz=1000), Parallels Desktop 26 on Apple Silicon drives the host CPU extremely hard even when the guest is idle. Reducing the timer frequency to 100 immediately normalizes CPU usage and prevents the VM from becoming sluggish or unresponsive. This strongly suggests a timing or interrupt‑rate handling issue in Parallels’ virtualization layer when running FreeBSD 14.3 on M‑series processors.
Regarding the setting: ACPI GED causes boot hangs or interrupt storms on 14.3
FreeBSD 14.3 frequently hangs during boot or becomes stuck in an ACPI interrupt storm unless ACPI GED is disabled. By disabling GED allows the system to boot cleanly and avoids the lockups described above. This points to an incompatibility between Parallels’ ACPI GED implementation and FreeBSD’s ACPI subsystem when running on Apple Silicon.
Hopefully this helps document these in the Parallels virtualization environment for Apple M-Series processors and allows anyone to investigate further as time allows to see if a bug can be addressed down the road for FreeBSD to not need the fix in the future or maybe this is by design?
Thank you all as always!