Return to Level1Techs.com

Kvmfr driver breaks other IVSHMEM devices

i am trying to use 2 IVSHMEM devices at once, one of these is for looking-glass. however, the looking-glass driver (kvmfr) prevents the system from loading virtio_pci for the other IVSHMEM device.

device 4 is looking-glass, device c is the one looking-glass’ driver breaks.

00:04.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01)
        Subsystem: Red Hat, Inc. QEMU Virtual Machine
        Physical Slot: 4
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Region 0: Memory at c0087000 (32-bit, non-prefetchable) [size=256]
        Region 2: Memory at 1010000000 (64-bit, prefetchable) [size=32M]
        Kernel driver in use: kvmfr
        Kernel modules: virtio_pci, kvmfr
00:0c.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01)
        Subsystem: Red Hat, Inc. QEMU Virtual Machine
        Physical Slot: 12
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Region 0: Memory at c0084000 (32-bit, non-prefetchable) [size=256]
        Region 2: Memory at 1012200000 (64-bit, prefetchable) [size=2M]
        Kernel driver in use: kvmfr
        Kernel modules: virtio_pci, kvmfr

any way to force the correct drivers onto their proper devices?

Why would you want to load virtio_pci for the IVSHMEM device?

this second device is my attempt to use scream’s IVSHMEM function to get audio from my windows VM to my Linux VM. this functionality requires virtio_pci

Sigh, don’t use IVSHMEM for SCREAM

Note: While this setup is possible it is ill-advised, Scream does not benefit from using IVSHMEM in any way, if anything it increases CPU load and latency due to the polling nature of the implementation. Scream operates far better over a vfio-net device which is already a zero-copy data transfer via shared memory. If you however insist on continuing you’re on your own if you run into issues.

https://looking-glass.hostfission.com/wiki/Using_Scream_over_IVSHMEM

You can get the audio from windows into another VM by using the jack audio backend in qemu 5.1 or later with Intel HDA audio devices in the guests. This is not only way more performant, it avoids the need to do anything special in the guest VMs and avoids the need to install an unsigned driver into the guest (Scream).

That said, if you insist on continuing, look at the kernel bind/unbind feature for all kernel modules.

1 Like