A few notes about 2018 macMini macOS host's virtualization vs. trying to install FreeBSD into such a VM

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 20 Nov 2022 22:04:25 UTC
Recent experiments were done trying to use a FreeBSD .img or .iso
for the Apple macOS 13.0.1's virtualization example that provides
a EFI/ACPI loading environment. After FreeBSD's EFI loader things
did not even get to seeing any kernel output. It is a macOS 2018
macMini environment, so amd64 FreeBSD.

So I installed a Fedora 37 Server via a .iso is order to see
what it would report as the environment it sees itself as
working in for a 2018 macMini under macOS 13.0.1. Apple's
software provides 4 GiBytes for the VM normally, but I'd
changed that as an experiment, thus, the 48 GiBytes below.
(macOS does not see a loss of 48 GiBytes as of when I'd
logged into the VM: It is not an up front allocation of that
much RAM.)

# lshw -short -numeric
H/W path      Device     Class          Description
                         system         Apple Virtualization Generic Platform
/0                       bus            Motherboard
/0/2                     processor      Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
/0/3                     memory         48GiB System Memory
/0/3/0                   memory         16GiB DIMM DRAM
/0/3/1                   memory         16GiB DIMM DRAM
/0/3/2                   memory         16GiB DIMM DRAM
/0/7                     memory         1MiB BIOS
/0/100                   bridge         Apple Inc. [106B:1A05]
/0/100/1                 network        Virtio network device [1AF4:1041]
/0/100/1/0    enp0s1     network        Ethernet interface
/0/100/5                 storage        Virtio block device [1AF4:1042]
/0/100/5/0    /dev/vda   disk           68GB Virtual I/O device
/0/100/5/0/1  /dev/vda1  volume         600MiB Apple HFS+ partition
/0/100/5/0/2  /dev/vda2  volume         1023MiB EFI partition
/0/100/5/0/3  /dev/vda3  volume         62GiB LVM Physical Volume
/0/100/6                 display        Virtio GPU [1AF4:1050]
/0/100/6/0               generic        Virtual I/O device
/0/100/7                 multimedia     Red Hat, Inc. [1AF4:1059]
/0/100/7/0               generic        Virtual I/O device
/0/100/8                 multimedia     Red Hat, Inc. [1AF4:1059]
/0/100/8/0               generic        Virtual I/O device
/0/100/9                 communication  Virtio console [1AF4:1043]
/0/100/9/0               generic        Virtual I/O device
/0/100/a                 bus            Apple Inc. [106B:1A06]
/0/100/a/0    usb1       bus            xHCI Host Controller [1D6B:2]
/0/100/a/0/1             input          Virtual USB Keyboard [5AC:8105]
/0/100/a/0/2             input          Virtual USB Digitizer [5AC:8106]
/0/100/a/1    usb2       bus            xHCI Host Controller [1D6B:3]
/0/100/1f                bridge         82801IR (ICH9R) LPC Interface Controller [8086:2916]
/0/0                     system         PnP device PNP0c02
/0/1                     system         PnP device PNP0b00

# lspci -nn
00:00.0 Host bridge [0600]: Apple Inc. Device [106b:1a05]
00:01.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1041] (rev 01)
00:05.0 Mass storage controller [0180]: Red Hat, Inc. Virtio block device [1af4:1042] (rev 01)
00:06.0 Display controller [0380]: Red Hat, Inc. Virtio GPU [1af4:1050] (rev 01)
00:07.0 Multimedia audio controller [0401]: Red Hat, Inc. Device [1af4:1059] (rev 01)
00:08.0 Multimedia audio controller [0401]: Red Hat, Inc. Device [1af4:1059] (rev 01)
00:09.0 Communication controller [0780]: Red Hat, Inc. Virtio console [1af4:1043] (rev 01)
00:0a.0 USB controller [0c03]: Apple Inc. Device [106b:1a06]
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IR (ICH9R) LPC Interface Controller [8086:2916]

This context, being Fedora 37 Server, is not using X11 or
such. I can (and do) ssh into the VM from the macMini's macOS.
This allows copy/paste, unlike the VM's own window. (My
understanding is that X11 use can be set up to do such.)

I can say that, with "quiet" removed from Fedora's kernel
command line, there is fairly early on (grabbed from
dmesg output):

[    0.134176] fbcon: Taking over console

It appears that, prior to that, I do not see much of anything
after grub. So I expect that is when the Fedora kernel
establishes its ability to make visible output via the VM.

Based on my FreeBSD experiments, the VM's EFI/ACPI loading
context requires the VM to have the "Virtio GPU" for it to
present the FreeBSD EFI loader UI --but once the FreeBSD EFI
loader hands off to FreeBSD's kernel, it may be that "Virtio
GPU" is the only way to see a UI, even a basic console.
FreeBSD does not have a virtio_gpu driver. (GPL2 licensing
issue involved in some of the source code in the normal

(FreeBSD also does not have a virtio audio driver.)

However, the failure seems immediate perceptually. An example

2022-11-14 20:25:26.386776-0800 GUIFreeBSDVirtualMachineSampleApp[9747:1406091] +[CATransaction synchronize] called within transaction
Virtual machine successfully started.
Virtual machine did stop with error: Internal Virtualization error. The virtual machine stopped unexpectedly.

For all I know, this could be happening before anything
related to video support in the FreeBSD kernel is involved.

I've no clue how to get evidence of what FreeBSD was doing
when then failure happens, given the in-VM context.

Another issue is that VZBridgedNetworkDeviceAttachment
(instead of the example's VZNATNetworkDeviceAttachment)

If you assign a VZBridgedNetworkDeviceAttachment object to this property, your app must have the com.apple.vm.networking entitlement. Without that entitlement, validation of your VZVirtualMachineConfiguration object fails."

( https://developer.apple.com/documentation/virtualization/vzbridgednetworkdeviceattachment )

but also:

This entitlement is restricted to developers of virtualization software. To request this entitlement, contact your Apple representative."

( https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_vm_networking )

Overall: unless someone with an appropriate knowledge base
happens to be motivated to try to make this VM context work
for FreeBSD (with NAT), it does not seem to be a viable
alternative for any kind of use without such an effort.

I'd expect Apple silicon macOS VM's to have the same sort
of properties for aarch64 FreeBSD. But I've no access to an
Apple silicon context to check with.

Mark Millard
marklmi at yahoo.com