FYI: I finally got FreeBSD 12 booted under qemu/kvm with general Ethernet access (on a MACCHIATObin running linux)

[Mark Millard]

Getting the general Ethernet access going involved
on the linux environment for the experiment running
head -r339076 under qemu/kvm:

# ip link add br0 type bridge
# ip link set eth2 master br0

The following file is not generic to all
linux's (neither are the eth2 references):

# more /etc/network/interfaces.d/br0
auto br0
iface br0 inet dhcp
    bridge_ports   eth2
    bridge_stp     off
    bridge_maxwait 0
    bridge_fd      0
iface br0 inet6 auto
    accept_ra 1

# more /etc/qemu-ifup
#!/bin/sh
set -x

if [ -n "$1" ];then
        ip tuntap add $1 mode tap user `whoami`
        ip link set $1 up
        sleep 0.5s
        ip link set $1 master br0
        exit 0
else
        echo "Error: no interface specified"
        exit 1
fi

I had built a more recent qemu than was the default
install for the environment. Thus the path below.
(I've omitted the MAC address that I used.)

# qemu-2.11.1/bin/debug/native/aarch64-softmmu/qemu-system-aarch64 \
                    -M virt,gic-version=2 \
                    -m 12288M -cpu host,pmu=off -smp 3 -enable-kvm \
                    -bios QEMU_EFI.fd \
                    -serial telnet::4444,server -nographic \
                    -drive if=none,format=raw,file=vm.raw,id=hd0 \
                    -device virtio-blk-device,drive=hd0 \
           -device e1000,netdev=net0,mac=OMITTED \
           -netdev tap,id=net0

(While I've tried a bunch of variations, I could easily be
doing something wrong invoking a qemu-system-aarch64 .)



Other notes/problems:

Unfortunately, like every past attempt at such where I used
-cpu host, -smp, and -enable-kvm on a few Linux-booted systems
where I've tried such, processes are subject to occasional, random
illegal instruction and segmentation fault program crashes. (The
host linux has no such problems.) True even before getting Ethernet
access working in FreeBSD.

sh, cron, vi, pkg, etc. with trackbacks of the call stacks for the
same program being generally widely varying from one to the next.
Even fairly early boot processes occasionally fail --and also late
processes during shutdown. It does seem to be able to sit idle over
night without generating any *.core files, at least sometimes. In
active use it has process crashes far more frequently. Building
software is not reasonable to do. Just getting pkg to download
and install something tends to be a retry-many-times context.

I have one /var/crash/ entry from a very late process crash,
but getting a copy out of the virtual machine would likely be
problematical. The system is non-debug but with symbols.

Historically debug kernel builds did not help me identify anything
specific. But I've not tried in this specific environment (yet).
(And my investigations tend to have a large dose of learn-as-I-go
instead of primarily being directly-apply-what-I-know. So I'm not
all that likely to identify anything rapidly.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)