Bug 255191

Comment 1 Aleksandr Fedorov 2021-04-21 09:09:32 UTC

Hello.

It's very strange that you are trying to start DragonFlyBSD using the bootloader from FreeBSD.

Yes, vmrun.sh, uses bhyveload(8) by default:

>FreeBSD/amd64 User boot lua, Revision 1.2
>Consoles: userboot

You should use -E option to choose UEFI bootloader.

I was able to successfully run it using the UEFI loader. But only if memory >= 4GB:

bhyve -H -A -P -c 1 -m 4G -s 0,hostbridge -s 1,virtio-blk,./dfly.img -s 2,ahci-cd,./dfly-x86_64-5.8.3_REL.iso -s 31,lpc -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd dfly

If you give the memory less than 4 gigabytes, then a similar error was occurs:

Unhandled memory access to 0x100000000
Failed to emulate instruction sequence [ 813c8f5f4d505f742483c20439d37f ] at 0xffffffff80bebe43

(In reply to Aleksandr Fedorov from comment #1)

Aleksandr,

thank you, I noticed too it was using the FreeBSD loader, but using the UEFI bootloader I got the same message. So it seems I copy/pasted the wrong extract (I wanted to copy the UEFI one), sorry about that.

I also tried on qemu/kvm on a Linux host I have because I don't own a machine with less than 4G and I can boot the installer without issues using only 1G or RAM for example. I've asked the DragonFlyBSD project on the meantime, and 4G of RAM is not required they say.

Using this virtual machine with 4G is acceptable for me, but I guess there's still something weird going on.

Comment 3 Peter Grehan 2021-04-21 12:27:04 UTC

I looked into this a while back: there are 2 issues
 - DFly is accessing memory beyond 4G when there is < 4G configured. This appears to be an array access in sys/platform/pc64/x86_64/mptable.c:mptable_search_sig()
   However, in PC-land this is allowed and accesses beyond the end of RAM will return 0xff's on a read.

 - bhyve does return 0xff's for reads beyond the end of memory, but doesn't implement that particular instruction (cmpl   $0x5f504d5f,(%rax,%rcx,4))

Rather than having to implement that instruction for such an edge condition, I'll try and resurrect the patch I once had (unfortunately lost) and get the fix into DFly.

(In reply to Peter Grehan from comment #3)
That's good news, though it probably won't be fixed before 6.0 RELEASE ?

Comment 5 Peter Grehan 2021-04-27 03:40:36 UTC

Created attachment 224465 [details]
dfly mptable diff

This should fix the issue in DFly.

The units of base_memory are KB, so this has to be adjusted before used as an absolute value, or this will result in a negative value just under 4G and the array access will then extend beyond 4G.

I suspect this will not be an issue systems other than bhyve since they would have a BIOS extended-data area and not execute this codepath, or even if they didn't, accessing memory beyond 4G would be a no-op.

In any case, it is an out-of-bounds array access, so worth fixing.

(In reply to Peter Grehan from comment #5)
Thank you for the patch. It solves the issue, I have tested it on DragonFly v6.0.0rc1-RELEASE.

(In reply to Marek Zarychta from comment #6)

Hello,

I can confirm that it's working for me too after applying the patch on the latest release candidate.

Peter,

The fix has been pushed on DragonFlyBSD side https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/70c69c34060140e40d6eff7ee0256cad8150bef3

So thank you, I think that bug can now be closed.

Comment 9 Peter Grehan 2021-04-27 22:10:49 UTC

Thanks for upstreaming the fix.