Date: Thu, 21 Sep 2023 01:36:35 -0500 From: Dustin Marquess <dmarquess@gmail.com> To: FreeBSD virtualization <freebsd-virtualization@freebsd.org>, =?utf-8?Q?Corvin_K=C3=B6hne?= <corvink@freebsd.org> Subject: Re: bhyve issues in 15-CURRENT Message-ID: <0ab66830-c168-4738-b1f2-d1071acebbe3@Spark> In-Reply-To: <3cf178349ce0483b031bc5705be33a177dabf1ba.camel@FreeBSD.org> References: <b4fd0c74-c077-475b-82e7-0477a3c5067a@Spark> <3c3ccffc-5a57-4472-8d16-5b5cdf5da862@Spark> <3cf178349ce0483b031bc5705be33a177dabf1ba.camel@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sep 21, 2023 at 1:29 AM -0500, Corvin Köhne <corvink@freebsd.org>, wrote: > On Wed, 2023-09-20 at 19:02 -0500, Dustin Marquess wrote: > > > > > > > > I just upgraded from a kernel+userland of 15-CURRENT from a release > > 20 days ago (git commit 565c887) to one today (git commit e39e6be). > > Afterwards, I've noticed two things that are probably really the same > > thing: > > > > - My Windows Server 2023 VM says that there's not enough resources > > for COM2 & COM4 > > - My OpenBSD 7.3 VM dies with: > > > > acpicmos0 at acpi0 > > "Bhyve_V_Gen_Counter_V1" at acpi0 not configured > > cpu0: using VERW MDS workaround > > pvbus0 at mainbus0: bhyve > > pci0 at mainbus0 bus 0 > > 0:3:0: io address conflict 0xc000/0x80 > > 0:5:0: io address conflict 0xc080/0x40 > > pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x7432 > > rev 0x00 > > virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev > > 0x00virtio0: can't map i/o space > > : Cannot attach (5) > > virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00 > > vio0 at virtio1: address 1e:17:37:23:2f:cb > > virtio1: msix per-VQ > > > > In this case, 0:3:0 is the virtio-blk device and 0:5:0 is the virtio- > > net device. > > > > If I boot it using a snapshot install74.img then it dies at: > > > > acpicmos0 at acpi0 > > "Bhyve_V_Gen_Counter_V1" at acpi0 not configured > > cpu0: using VERW MDS workaround > > pvbus0 at mainbus0: bhyve > > pci0 at mainbus0 bus 0 > > 0:2:0: io address conflict 0xc080/0x80 > > 0:3:0: io address conflict 0xc000/0x80 > > 0:5:0: io address conflict 0xc100/0x40 > > pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x7432 > > rev 0x00 > > virtio0 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev > > 0x00virtio0: can't map i/o space > > : Cannot attach (5) > > virtio1 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00 > > vioblk0 at virtio1 > > scsibus0 at vioblk0: 1 targets > > sd0 at scsibus0 targ 0 lun 0: <VirtIO, Block Device, > > > sd0: 8192MB, 512 bytes/sector, 16777216 sectors > > virtio1: msix per-VQ > > virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00 > > vio0 at virtio2: address ff:ff:ff:ff:ff:ff > > panic: vq_size not power of two: 65535 > > > > 0:3:0 are virtio-blk and 0:5:0 is virtio-net, as above. 0:2:0 is the > > extra virtio-blk for the .img file. > > > > Any ideas on what change caused this? > Please make sure to call bhyve with the -A option. Yep, my script runs it as: bhyve -A -D -H -P -w -S -u -c $CPUS -m $RAM \ -s 0,amd_hostbridge \ -s 3,virtio-blk,/dev/zvol/tank/vm/$VM \ -s 5,virtio-net,tap0,mac=1e:17:37:23:2f:cb \ -s 31,lpc \ -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd $VM So -A is there already. -Dustin [-- Attachment #2 --] <html xmlns="http://www.w3.org/1999/xhtml">; <head> <title></title> </head> <body> <div name="messageReplySection"> <div dir="auto">On Sep 21, 2023 at 1:29 AM -0500, Corvin Köhne <corvink@freebsd.org>, wrote:</div> <blockquote style="border-left-color: rgb(26, 188, 156); margin: 5px; padding-left: 10px; border-left-width: thin; border-left-style: solid;">On Wed, 2023-09-20 at 19:02 -0500, Dustin Marquess wrote:<br /> <blockquote style="border-left-color: rgb(230, 126, 34); margin: 5px; padding-left: 10px; border-left-width: thin; border-left-style: solid;"><br /> <br /> <br /> I just upgraded from a kernel+userland of 15-CURRENT from a release<br /> 20 days ago (git commit 565c887) to one today (git commit e39e6be).<br /> Afterwards, I've noticed two things that are probably really the same<br /> thing:<br /> <br /> - My Windows Server 2023 VM says that there's not enough resources<br /> for COM2 & COM4<br /> - My OpenBSD 7.3 VM dies with:<br /> <br /> acpicmos0 at acpi0<br /> "Bhyve_V_Gen_Counter_V1" at acpi0 not configured<br /> cpu0: using VERW MDS workaround<br /> pvbus0 at mainbus0: bhyve<br /> pci0 at mainbus0 bus 0<br /> 0:3:0: io address conflict 0xc000/0x80<br /> 0:5:0: io address conflict 0xc080/0x40<br /> pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x7432<br /> rev 0x00<br /> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev<br /> 0x00virtio0: can't map i/o space<br /> : Cannot attach (5)<br /> virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00<br /> vio0 at virtio1: address 1e:17:37:23:2f:cb<br /> virtio1: msix per-VQ<br /> <br /> In this case, 0:3:0 is the virtio-blk device and 0:5:0 is the virtio-<br /> net device.<br /> <br /> If I boot it using a snapshot install74.img then it dies at:<br /> <br /> acpicmos0 at acpi0<br /> "Bhyve_V_Gen_Counter_V1" at acpi0 not configured<br /> cpu0: using VERW MDS workaround<br /> pvbus0 at mainbus0: bhyve<br /> pci0 at mainbus0 bus 0<br /> 0:2:0: io address conflict 0xc080/0x80<br /> 0:3:0: io address conflict 0xc000/0x80<br /> 0:5:0: io address conflict 0xc100/0x40<br /> pchb0 at pci0 dev 0 function 0 vendor "AMD", unknown product 0x7432<br /> rev 0x00<br /> virtio0 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev<br /> 0x00virtio0: can't map i/o space<br /> : Cannot attach (5)<br /> virtio1 at pci0 dev 3 function 0 "Qumranet Virtio Storage" rev 0x00<br /> vioblk0 at virtio1<br /> scsibus0 at vioblk0: 1 targets<br /> sd0 at scsibus0 targ 0 lun 0: <VirtIO, Block Device, ><br /> sd0: 8192MB, 512 bytes/sector, 16777216 sectors<br /> virtio1: msix per-VQ<br /> virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00<br /> vio0 at virtio2: address ff:ff:ff:ff:ff:ff<br /> panic: vq_size not power of two: 65535<br /> <br /> 0:3:0 are virtio-blk and 0:5:0 is virtio-net, as above. 0:2:0 is the<br /> extra virtio-blk for the .img file.<br /> <br /> Any ideas on what change caused this?</blockquote> Please make sure to call bhyve with the -A option.</blockquote> <div dir="auto"><br /> Yep, my script runs it as:<br /> <br /> bhyve -A -D -H -P -w -S -u -c $CPUS -m $RAM \<br /> -s 0,amd_hostbridge \<br /> -s 3,virtio-blk,/dev/zvol/tank/vm/$VM \<br /> -s 5,virtio-net,tap0,mac=1e:17:37:23:2f:cb \<br /> -s 31,lpc \<br /> -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd $VM<br /> <br /> So -A is there already.<br /> <br /> -Dustin</div> </div> </body> </html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0ab66830-c168-4738-b1f2-d1071acebbe3>