Date: Sun, 7 Oct 2018 12:14:59 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: FYI: I finally got FreeBSD 12 booted under qemu/kvm with general Ethernet access (on a MACCHIATObin running linux) Message-ID: <F52711CD-048D-4820-9883-0A60475BD688@yahoo.com>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F52711CD-048D-4820-9883-0A60475BD688>