[Bug 236922] Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Tue Jan 7 00:17:56 UTC 2020
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922
--- Comment #18 from Tommy P <tommyhp2 at gmail.com> ---
(In reply to John Hartley from comment #16)
Thanks John for the feedback. Are you using the default GENERIC kernel? I
didn't have any issues with my custom (trimmed of the GENERIC by removing
unused drivers) kernel in conjunction with i440FX chipset. All of the VirtIO
(block devices, NIC, memory balloon, etc) work OK. All of the SCSI controllers
(Hypervisor default and VirtIO SCSI models) in addition VirtIO Serial work OK.
It's when I created a VM configuration with Q35 chipset instead of i440FX that
none of the VirtIO devices (including the VirtIO Serial & SCSI) are working as
per my previous troubleshooting (comment #5 - #7). Thus, I don't think it's
relating the OVMF firmware configuration within KVM-QEMU nor the FreeBSD
version. I'm pretty sure it's how the VirtIO devices are detected and loaded
as per FreeBSD's source code /usr/src/sys/dev/virtio/virtio_ids.h. If you
compare the pciconf on a working i440FX VM system vs. a non working Q35 VM,
you'll notice the matching 'card' ID to virtio_ids.h on the working i440FX VM
while the non-working Q35 VM doesn't have any. For example:
none2 at pci0:2:0:0: class=0x010000 card=0x11001af4 chip=0x10481af4 rev=0x01
hdr=0x00
vendor = 'Red Hat, Inc.'
device = 'Virtio SCSI'
class = mass storage
subclass = SCSI
Here are the images of the my config:
https://imgur.com/a/rftzjO3
Devices that are loaded and not loaded (no driver attached)
root at d-fbsd:~ # ls /dev/*da*
/dev/ada0 /dev/ada1 /dev/ada2p1 /dev/ada4 /dev/ada5p1
/dev/da1 /dev/da2p1 /dev/da4 /dev/da5p1 /dev/da6p1
/dev/ada0p1 /dev/ada1p1 /dev/ada3 /dev/ada4p1 /dev/da0
/dev/da1p1 /dev/da3 /dev/da4p1 /dev/da5p2 /dev/da6p2
/dev/ada0p2 /dev/ada2 /dev/ada3p1 /dev/ada5 /dev/da0p1
/dev/da2 /dev/da3p1 /dev/da5 /dev/da6
root at d-fbsd:~ # dmesg | egrep -i 'scsi|mass stor|sym'
pci2: <mass storage, SCSI> at device 0.0 (no driver attached)
sym0: <895a> port 0xe000-0xe0ff mem 0xfca02000-0xfca023ff,0xfca00000-0xfca01fff
irq 22 at device 0.0 on pci4
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
sym1: <895a> port 0xd000-0xd0ff mem 0xfc802000-0xfc8023ff,0xfc800000-0xfc801fff
irq 22 at device 0.0 on pci5
sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking
da0 at sym0 bus 0 scbus0 target 0 lun 0
da0: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
pass13: da1 at sym0 bus 0 scbus0 target 1 lun 0
<QEMU QEMU DVD-ROM 2.5+> Removable CD-ROM SCSI device
da1: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
da2 at sym0 bus 0 scbus0 target 2 lun 0
pass13: 150.000MB/s transfers
da2: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
da3 at sym0 bus 0 scbus0 target 3 lun 0
da3: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
da4 at sym0 bus 0 scbus0 target 4 lun 0
da4: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
da5 at sym1 bus 0 scbus1 target 5 lun 0
da5: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
da6 at sym1 bus 0 scbus1 target 6 lun 0
da6: <QEMU QEMU HARDDISK 2.5+> Fixed Direct Access SPC-3 SCSI device
root at d-fbsd:~ # uname -a
FreeBSD d-fbsd 11.2-RELEASE-p15 FreeBSD 11.2-RELEASE-p15 #0 r356353: Sat Jan 4
16:10:17 PST 2020 root at d-fbsd:/usr/obj/usr/src11.2/sys/Custom amd64
Regarding the matrix, from my troubleshooting, everything should work as long
as you use the i440FX. If you decide to use the Q35, do not use anything
relating to VirtIO (SCSI and Serial storages, NIC, etc). BTW, if you use shell
scripts to maintain your VMs, simply changing the configuration of i440FX to
Q35 only would still work since the existing VirtIO devices are attached to the
PCI-ISA bus instead of PCIe-PCI (please see
https://forums.freebsd.org/threads/freebsd-12-release-guest-in-qemu-kvm.70207/
and https://wiki.qemu.org/Features/Q35).
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-virtualization
mailing list