[Bug 276575] Host can cause a crash in bhyve nvme emulation

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 24 Jan 2024 00:45:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276575

--- Comment #1 from Duncan <dpy@pobox.com> ---
Apologies, adding the attachment posted the first comment. I can't seem to be
able to edit it, so this is an addition.

Host is 128GB Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz (6 core).

I have attached the minidump from the windows vm crashing itself due to
continuous high diskIO.

As I mentioned the case of a high disk load (reads) on the host resulting in a
corrupted disk image (due to the disk unexpectedly disappearing from windows)
is more worrying for me.

I have reverted all my VMs back to virtIO-blk.

On the weekend I will shutdown the vm, snapshot, change back to nvme, turn on
debug and try some more scenarios.

Any suggestions would be welcome.

The vm-bhyve config file is as follows (both guests have the same setup):

#---------------------------------------------
loader="uefi"
bhyve_options="-A"
graphics="yes"
graphics_res="1600x900"
graphics_port="5915"
vnc_password="########"
xhci_mouse="yes"

cpu_sockets=1
cpu_cores=5
cpu=5

wired_memory="yes"
memory=20G

#debug="yes"

# put up to 8 disks on a single ahci controller.
# without this, adding a disk pushes the following network devices onto higher
slot numbers,
# which causes windows to see them as a new interface
ahci_device_limit="8"

# ideally this should be changed to virtio-net and drivers installed in the
guest
# e1000 works out-of-the-box
#network0_type="e1000"
network0_type="virtio-net"
network0_switch="lan"

#disk0_type="nvme"
disk0_type="virtio-blk"
disk0_name="disk0.img"

#disk1_type="nvme"
disk1_type="virtio-blk"
disk1_name="disk1.img"

#disk2_type="nvme"
disk2_type="virtio-blk"
disk2_name="disk2.img"

disk3_type="ahci-cd"
disk3_dev="custom"
disk3_name="/vm/.iso/virtio-win.iso


# windows expects the host to expose localtime by default, not UTC
utctime="no"
uuid="291ee834-f125-11ec-8580-d05099d1a548"
network0_mac="#################"
#----------------------------------------------

Regards

Duncan

-- 
You are receiving this mail because:
You are the assignee for the bug.