gnif / LookingGlass

An extremely low latency KVMFR (KVM FrameRelay) implementation for guests with VGA PCI Passthrough.
GNU General Public License v2.0
4.72k stars 262 forks source link

Looking Glass host, if running as a service, ignores ini file if IVSHMEM 0 is of not sufficient size instead of using IVSHMEM 1 as specified in the config #1006

Closed Lissanro closed 2 years ago

Lissanro commented 2 years ago

In virt-manager I have two shmem devices, the first one for Looking Glass and another for Scream.

  <qemu:commandline>
    <qemu:arg value="-device"/>
    <qemu:arg value="ivshmem-plain,id=shmem0,memdev=looking-glass"/>
    <qemu:arg value="-object"/>
    <qemu:arg value="memory-backend-file,id=looking-glass,mem-path=/dev/kvmfr0,size=64M,share=yes"/>
    <qemu:arg value="-device"/>
    <qemu:arg value="ivshmem-plain,id=shmem1,memdev=scream"/>
    <qemu:arg value="-object"/>
    <qemu:arg value="memory-backend-file,id=scream,mem-path=/dev/shm/scream,size=2M,share=yes"/>
  </qemu:commandline>

My first attempt to make Looking Glass work was fruitless, it kept ignoring ini file and insisted using IVSHMEM 0. After spending some time, I managed to make it so IVSHMEM 0 is of 64MB size, but after I rebooted my PC, it became IVSHMEM 1 again. I did not understand at first why the Looking Glass service ignores ini file.

It is notable that my ini file worked, I had specified d3d12 copyBackend, and this was reflected in the log files as expected. But now (after IVSHMEM 0 became IVSHMEM 1, and I tried to add shmDevice=1 to the config) I see that ini file also ignored:

[I]   9215839999           ivshmem.c:132  | ivshmemInit                    | IVSHMEM 0* on bus 0x0, device 0x11, function 0x0
[I]   9215842300           ivshmem.c:132  | ivshmemInit                    | IVSHMEM 1  on bus 0x4, device 0x1, function 0x0
[I]   9215843815               app.c:785  | app_main                       | IVSHMEM Size     : 2 MiB
[I]   9215844361               app.c:786  | app_main                       | IVSHMEM Address  : 0x3AC0000
...
[I]   9216001920              dxgi.c:666  | dxgi_init                      | Copy backend      : Direct3D 11
...
[E]   9216004145               app.c:678  | lgmpSetup                      | lgmpHostMemAlloc Failed (Pointer Shapes): LGMP_ERR_NO_SHARED_MEM

My config file:

[os]
shmDevice=1

[app]
capture=DXGI

[dxgi]
dwmFlush=yes
copyBackend=d3d12
disableDamage=yes
d3d12CopySleep=5.0

I had to use disableDamage=yes otherwise I had glitches, but for this bug report, this is not relevant, because copyBackend=d3d12 is completely ignored if IVSHMEM 0 is not of sufficient size, and shmDevice=1 is also ignored.

This makes no sense to me, because if I cd to the directory whele Looking Glass host is installed, and run .\looking-glass-host.exe -h, it suddenly starts reading the ini file:

  | os:logFile   |       | C:\ProgramData\Looking Glass (host)\looking-glass-host.txt | The log file to write to                  |
  | os:exitEvent |       |                                                            | Exit when the specified event is signaled |
  | os:shmDevice |       | 1                                                          | The IVSHMEM device to use                 |
  +--------------+-------+------------------------------------------------------------+-------------------------------------------+
...
  | dxgi:copyBackend    |       | d3d12    | The copy backend to use, i.e. d3d11 or d3d12                                               |
  | dxgi:disableDamage  |       | yes      | Do not do damage-aware copies, i.e. always do full frame copies                            |
  | dxgi:d3d12CopySleep |       | 5.000000 | Milliseconds to sleep before copying frame with d3d12                                      |

And if I run it as .\looking-glass-host.exe, it works. Yes, I am sure the service points to the right file and I do not have any other installation, and I also tried to uninstall and install the service again by running:

.\looking-glass-host.exe UninstallService
.\looking-glass-host.exe InstallService

But this unfortunatelly does not help.

Even if this issue is fixed, I think it would be better if Looking Glass detected right device ID based on its size. For example, if I want to use 64MB device, there is no reason to try 2MB device and fail. This is how Scream service works, after I specify IVSHMEM size, it looks for it, and then it works regardless of possible ID changes.

I found no reliable way to force IVSHMEM for Looking Glass to have ID 0, it does not read the ini file because of this, so it does not work as a service for me. Uninstalling it as a service and manually adding to startup does not work either, if IVSHMEM 0 is 2MB device. But I can startup Looking Glass host manually, either from the terminal or from Start menu.

Lissanro commented 2 years ago

Sorry, disregard this issue. After I deleted log files, without doing any other changes, the service started working. Not sure what was wrong. Maybe permission issue or something. I am not sure if log files were updated correctly when it was starting as a service, so perhaps it was reading ini file correctly after all, but crashed because something was wrong with the log files.

gnif commented 2 years ago

Also don't use SCREAM.

https://github.com/duncanthrax/scream#using-ivshmem-between-windows-guest-and-linux-host

warning Note: While this setup is possible, it is generally only advised if you can't use network transfer via a standard virtio-net device. Scream on QEMU does not benefit from using IVSHMEM. It increases CPU load and latency due to the polling nature of the implementation.

Either use QEMUs native audio output support, or upgrade to Looking Glass bleeding edge (or wait for B6) which has native audio support built in.