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

[Mark Millard]

On 2018-Oct-8, at 1:07 PM, Mark Millard <marklmi at yahoo.com> wrote:

> On 2018-Oct-8, at 12:26 PM, Greg V <greg at unrelenting.technology> wrote:
> 
>> On Mon, Oct 8, 2018 at 10:14 PM, Mark Millard <marklmi at yahoo.com> wrote:
>>> On 2018-Oct-8, at 11:41 AM, Greg V <greg at unrelenting.technology> wrote:
>>>> On Sun, Oct 7, 2018 at 10:14 PM, Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
>>>>> 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.
>>>> Hmmmm, I never saw any program crashes on Scaleway's KVM VPS (ThunderX hardware), but I have awfully slow storage performance.
>>>> How fast is the disk on your KVM setup?
>>> I've only booted linux via a microsd card so far,
>>> a Class A1 SanDisk Ultra. I've not planned on
>>> putting linux on the fast media that I hope
>>> to put FreeBSD on and boot from someday. As
>>> stands, I do not have spare fast media for the
>>> MACCHIATObin.
>> 
>> Surely QEMU/KVM supports booting from bare metal hard disks (not files), so you could put FreeBSD on the disk you want to eventually boot directly from, and initially try it under KVM. I actually had a setup where I would boot the same FreeBSD disk on my desktop both directly on metal and under Hyper-V :)
> 
> I do that under Hyper-V (Windows 10 Pro) and directly. But
> linux/qemu/kvm is effectively new to me and everything is
> exploratory. I may get there.
> 
>> But anyway, I think you'd notice the difference even on microSD.
>> The performance on the VPS is *that* bad.
>> 
> 
> At some point I may be I can run something
> like:
> 
> iozone -a -a0 -a1 -a2 -e -I
> 
> for you and supply some of the output
> (from a run that does not crash first).
> The -e and -I tend to avoid measuring
> oeprations that have not (yet) gone to
> the storage media or are just in cache.

iozone turned out to be a non-useful idea:
It comes up with a bunch of speeds being
way over 100000 KBytes/s for reclen's
of 32 KBytes or more, even a re-read of
1069489 KBytes/s and a read of 915107
KBytes/s are examples.

There may be caching/buffering in qemu/kvm/linux
not under control of the -e and -I (and FreeBSD)
and/or time may not measure out well. I'm not
going to try to figure the contributions at this
point.

iozone also gets SIGSEGV at some random point,
possibly more reliably than other things
that have produced core files in what little
that I've done with FreeBSD in this context.

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