You are not logged in.
Hi
my system is x64(AMD Ryzen Threadripper) & gpu is AMD(Radeon Pro WX)
Create one guest in libvirt run & work correctly :
<domain type='kvm'>
<name>archlinux-sway4</name>
<uuid>38f69f41-4f22-4c6b-ac0a-35c7ae1be4e2</uuid>
<metadata>
<libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="http://archlinux.org/archlinux/rolling"/>
</libosinfo:libosinfo>
</metadata>
<memory unit='KiB'>8388608</memory>
<currentMemory unit='KiB'>8388608</currentMemory>
<vcpu placement='static'>6</vcpu>
<os firmware='efi'>
<type arch='x86_64' machine='pc-q35-8.1'>hvm</type>
<firmware>
<feature enabled='no' name='enrolled-keys'/>
<feature enabled='yes' name='secure-boot'/>
</firmware>
<loader readonly='yes' secure='yes' type='pflash'>/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd</loader>
<nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd'>/var/lib/libvirt/qemu/nvram/archlinux-sway4_VARS.fd</nvram>
</os>
<features>
<acpi/>
<apic/>
<vmport state='off'/>
<smm state='on'/>
</features>
<cpu mode='host-passthrough' check='none' migratable='on'/>
<clock offset='utc'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/mnt/N2/VM1/VM-Uni/archlinux-sway4.qcow2'/>
<target dev='vda' bus='virtio'/>
<boot order='1'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/mz/Downloads/manjaro-sway-22.1.2-230827-linux61.iso'/>
<target dev='sda' bus='sata'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='usb' index='0' model='qemu-xhci' ports='15'>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</controller>
<controller type='pci' index='0' model='pcie-root'/>
<controller type='pci' index='1' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='1' port='0x10'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='2' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='2' port='0x11'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
</controller>
<controller type='pci' index='3' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='3' port='0x12'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
</controller>
<controller type='pci' index='4' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='4' port='0x13'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
</controller>
<controller type='pci' index='5' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='5' port='0x14'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
</controller>
<controller type='pci' index='6' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='6' port='0x15'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
</controller>
<controller type='pci' index='7' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='7' port='0x16'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
</controller>
<controller type='pci' index='8' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='8' port='0x17'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/>
</controller>
<controller type='pci' index='9' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='9' port='0x18'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='10' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='10' port='0x19'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/>
</controller>
<controller type='pci' index='11' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='11' port='0x1a'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/>
</controller>
<controller type='pci' index='12' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='12' port='0x1b'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/>
</controller>
<controller type='pci' index='13' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='13' port='0x1c'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/>
</controller>
<controller type='pci' index='14' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='14' port='0x1d'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/>
</controller>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<controller type='virtio-serial' index='0'>
<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</controller>
<interface type='network'>
<mac address='88:88:00:51:82:f9'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</interface>
<serial type='pty'>
<target type='isa-serial' port='0'>
<model name='isa-serial'/>
</target>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<channel type='unix'>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0'/>
<address type='virtio-serial' controller='0' bus='0' port='2'/>
</channel>
<input type='tablet' bus='usb'>
<address type='usb' bus='0' port='1'/>
</input>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='spice'>
<listen type='none'/>
<gl enable='no'/>
</graphics>
<sound model='ich9'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
</sound>
<audio id='1' type='spice'/>
<video>
<model type='virtio' heads='1' primary='yes'>
<acceleration accel3d='no'/>
</model>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</video>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='2'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='3'/>
</redirdev>
<watchdog model='itco' action='reset'/>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
</memballoon>
<rng model='virtio'>
<backend model='random'>/dev/urandom</backend>
<address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
</rng>
</devices>
</domain>My GPU is AMD :
name of display: :1
display: :1 screen: 0
Direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: AMD (0x1002)
Device: AMD Radeon Pro WX 7100 Graphics (polaris10, LLVM 16.0.6, DRM 3.52, 6.4.12-arch1-1) (0x67c4)
Version: 23.1.6
Accelerated: yes
Video memory: 8192MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 5989 MB, largest block: 5989 MB
VBO free aux. memory - total: 64166 MB, largest block: 64166 MB
Texture free memory - total: 5989 MB, largest block: 5989 MB
Texture free aux. memory - total: 64166 MB, largest block: 64166 MB
Renderbuffer free memory - total: 5989 MB, largest block: 5989 MB
Renderbuffer free aux. memory - total: 64166 MB, largest block: 64166 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 8192 MB
Total available memory: 72506 MB
Currently available dedicated video memory: 5989 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon Pro WX 7100 Graphics (polaris10, LLVM 16.0.6, DRM 3.52, 6.4.12-arch1-1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.1.6-arch1.4
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.6-arch1.4
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.1.6-arch1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20Now changing to use 3D via VGL
...
<graphics type="spice">
<listen type="none"/>
<gl enable="yes"/>
</graphics>
....
...
<video>
<model type="virtio" heads="1" primary="yes">
<acceleration accel3d="yes"/>
</model>
<address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>
...But upper change to active OpenGL & running guest VM get an error :
virsh start archlinux-sway4
error: Failed to start domain 'archlinux-sway4'
error: internal error: QEMU unexpectedly closed the monitor (vm='archlinux-sway4'
Journal:
...
ibvirtd[85947]: Unable to read from monitor: Connection reset by peer
libvirtd[85947]: internal error: QEMU unexpectedly closed the monitor (vm='archlinux-sway4')
....
Offline
Does it work if you omit the "acceleration accel3d" change and only change the "gl enable" setting ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Does it work if you omit the "acceleration accel3d" change and only change the "gl enable" setting ?
It has the same error when only: gl enable="yes"
Offline
Can you retrieve the guest journal from the fail ?
Please also post full lspci -k & lscpu output and journal, all for the host.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Can you retrieve the guest journal from the fail ?
Please also post full lspci -k & lscpu output and journal, all for the host.
journal:
Sep 05 18:07:41 mz-tr4b polkitd[1302]: Registered Authentication Agent for unix-process:15724:1753624 (system bus name :1.259 [/usr/bin/pkttyagent --process 15724 --notify-fd 4 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Sep 05 18:07:41 mz-tr4b polkitd[1302]: Unregistered Authentication Agent for unix-process:15724:1753624 (system bus name :1.259, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.5894] manager: (vnet1): new Tun device (/org/freedesktop/NetworkManager/Devices/8)
Sep 05 18:07:41 mz-tr4b kernel: virbr0: port 1(vnet1) entered blocking state
Sep 05 18:07:41 mz-tr4b kernel: virbr0: port 1(vnet1) entered disabled state
Sep 05 18:07:41 mz-tr4b kernel: vnet1: entered allmulticast mode
Sep 05 18:07:41 mz-tr4b kernel: vnet1: entered promiscuous mode
Sep 05 18:07:41 mz-tr4b kernel: virbr0: port 1(vnet1) entered blocking state
Sep 05 18:07:41 mz-tr4b kernel: virbr0: port 1(vnet1) entered listening state
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6027] device (vnet1): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6035] device (vnet1): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6042] device (vnet1): Activation: starting connection 'vnet1' (a99cf5c7-00a9-497c-9e1a-76c0eb48d8ba)
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6045] device (vnet1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6049] device (vnet1): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6051] device (vnet1): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6053] device (virbr0): bridge port vnet1 was attached
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6053] device (vnet1): Activation: connection 'vnet1' enslaved, continuing activation
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6116] device (vnet1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b dbus-daemon[1261]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.10' (uid=0 pid=1348 comm="/usr/bin/NetworkManager --no-daemon")
Sep 05 18:07:41 mz-tr4b virtnodedevd[8308]: Failed to open a VPD file '/sys/bus/pci/devices/0000:45:00.0/vpd': Operation not permitted
Sep 05 18:07:41 mz-tr4b virtnodedevd[8308]: Failed to open a VPD file '/sys/bus/pci/devices/0000:47:00.0/vpd': Operation not permitted
Sep 05 18:07:41 mz-tr4b systemd[1]: Starting Network Manager Script Dispatcher Service...
Sep 05 18:07:41 mz-tr4b systemd[1]: /usr/lib/systemd/system/virtqemud.service:29: Unknown key name 'LimitNOFile' in section 'Service', ignoring.
Sep 05 18:07:41 mz-tr4b systemd-machined[1271]: New machine qemu-3-archlinux-sway4.
Sep 05 18:07:41 mz-tr4b dbus-daemon[1261]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6736] device (vnet1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6738] device (vnet1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.6743] device (vnet1): Activation: successful, device activated.
Sep 05 18:07:41 mz-tr4b systemd[1]: Started Virtual Machine qemu-3-archlinux-sway4.
Sep 05 18:07:41 mz-tr4b systemd[1]: Started Network Manager Script Dispatcher Service.
Sep 05 18:07:41 mz-tr4b kernel: audit: type=1326 audit(1693924661.803:2): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=15756 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f521ceda0d7 code=0x80000000
Sep 05 18:07:41 mz-tr4b systemd[1]: Started Process Core Dump (PID 15779/UID 0).
Sep 05 18:07:41 mz-tr4b kernel: virbr0: port 1(vnet1) entered disabled state
Sep 05 18:07:41 mz-tr4b kernel: vnet1 (unregistering): left allmulticast mode
Sep 05 18:07:41 mz-tr4b kernel: vnet1 (unregistering): left promiscuous mode
Sep 05 18:07:41 mz-tr4b kernel: virbr0: port 1(vnet1) entered disabled state
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.9373] device (vnet1): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
Sep 05 18:07:41 mz-tr4b NetworkManager[1348]: <info> [1693924661.9376] device (vnet1): released from master device virbr0
Sep 05 18:07:41 mz-tr4b libvirtd[8337]: Unable to read from monitor: Connection reset by peer
Sep 05 18:07:41 mz-tr4b libvirtd[8337]: internal error: QEMU unexpectedly closed the monitor (vm='archlinux-sway4')
Sep 05 18:07:41 mz-tr4b systemd[1]: machine-qemu\x2d3\x2darchlinux\x2dsway4.scope: Deactivated successfully.
Sep 05 18:07:42 mz-tr4b systemd-coredump[15780]: Resource limits disable core dumping for process 15756 (qemu-system-x86).lspci -k
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
Subsystem: ASRock Incorporation Starship/Matisse Root Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
Subsystem: ASRock Incorporation FCH SMBus Controller
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
Subsystem: ASRock Incorporation FCH LPC Bridge
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 3
Kernel driver in use: k10temp
Kernel modules: k10temp
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship Device 24; Function 7
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon Pro WX 7100]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon Pro WX 7100]
Kernel driver in use: amdgpu
Kernel modules: amdgpu
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
02:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
03:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller
Subsystem: ASRock Incorporation Starship USB 3.0 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
20:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
20:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
20:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
20:03.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
20:03.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
20:03.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
20:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
20:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
20:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
21:00.0 Non-Volatile memory controller: Phison Electronics Corporation E18 PCIe4 NVMe Controller (rev 01)
Subsystem: Phison Electronics Corporation E18 PCIe4 NVMe Controller
Kernel driver in use: nvme
Kernel modules: nvme
22:00.0 Non-Volatile memory controller: Phison Electronics Corporation E18 PCIe4 NVMe Controller (rev 01)
Subsystem: Phison Electronics Corporation E18 PCIe4 NVMe Controller
Kernel driver in use: nvme
Kernel modules: nvme
23:00.0 Non-Volatile memory controller: Phison Electronics Corporation E18 PCIe4 NVMe Controller (rev 01)
Subsystem: Phison Electronics Corporation E18 PCIe4 NVMe Controller
Kernel driver in use: nvme
Kernel modules: nvme
24:00.0 Non-Volatile memory controller: Phison Electronics Corporation E16 PCIe4 NVMe Controller (rev 01)
Subsystem: Phison Electronics Corporation E16 PCIe4 NVMe Controller
Kernel driver in use: nvme
Kernel modules: nvme
25:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
26:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
26:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP
Kernel driver in use: ccp
Kernel modules: ccp
26:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller
Subsystem: ASRock Incorporation Starship USB 3.0 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
26:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
40:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
40:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
40:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
40:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
40:03.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
Kernel driver in use: pcieport
40:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
40:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
40:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
41:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse Switch Upstream
Kernel driver in use: pcieport
42:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
42:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
Kernel driver in use: pcieport
43:00.0 Non-Volatile memory controller: Phison Electronics Corporation E18 PCIe4 NVMe Controller (rev 01)
Subsystem: Phison Electronics Corporation E18 PCIe4 NVMe Controller
Kernel driver in use: nvme
Kernel modules: nvme
44:00.0 USB controller: ASMedia Technology Inc. ASM3242 USB 3.2 Host Controller
Subsystem: ASMedia Technology Inc. ASM3242 USB 3.2 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
45:00.0 Ethernet controller: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02)
Subsystem: ASRock Incorporation AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]
Kernel driver in use: atlantic
Kernel modules: atlantic
46:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
Subsystem: Intel Corporation Wi-Fi 6 AX200NGW
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
47:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 01)
Subsystem: ASRock Incorporation RTL8125 2.5GbE Controller
Kernel driver in use: r8169
Kernel modules: r8169
48:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
48:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
48:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
49:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
Kernel driver in use: ahci
4a:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
Kernel driver in use: ahci
4b:00.0 PCI bridge: PLX Technology, Inc. Device 8714 (rev ab)
Subsystem: PLX Technology, Inc. Device 8714
Kernel driver in use: pcieport
4c:01.0 PCI bridge: PLX Technology, Inc. Device 8714 (rev ab)
Subsystem: PLX Technology, Inc. Device 8714
Kernel driver in use: pcieport
4c:02.0 PCI bridge: PLX Technology, Inc. Device 8714 (rev ab)
Subsystem: PLX Technology, Inc. Device 8714
Kernel driver in use: pcieport
4c:03.0 PCI bridge: PLX Technology, Inc. Device 8714 (rev ab)
Subsystem: PLX Technology, Inc. Device 8714
Kernel driver in use: pcieport
4c:04.0 PCI bridge: PLX Technology, Inc. Device 8714 (rev ab)
Subsystem: PLX Technology, Inc. Device 8714
Kernel driver in use: pcieport
4e:00.0 USB controller: ASMedia Technology Inc. ASM2142/ASM3142 USB 3.1 Host Controller
Subsystem: ASMedia Technology Inc. ASM2142/ASM3142 USB 3.1 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
50:00.0 USB controller: ASMedia Technology Inc. ASM2142/ASM3142 USB 3.1 Host Controller
Subsystem: ASMedia Technology Inc. ASM2142/ASM3142 USB 3.1 Host Controller
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
52:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
53:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
60:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex
60:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU
60:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
60:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge
60:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B]
Kernel driver in use: pcieport
61:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function
62:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPPLast edited by maziar (2023-09-05 14:44:20)
Offline
That's not all I asked for, but it's enough to continue .
Sep 05 18:07:41 mz-tr4b virtnodedevd[8308]: Failed to open a VPD file '/sys/bus/pci/devices/0000:45:00.0/vpd': Operation not permitted
Sep 05 18:07:41 mz-tr4b virtnodedevd[8308]: Failed to open a VPD file '/sys/bus/pci/devices/0000:47:00.0/vpd': Operation not permitted
Sep 05 18:07:41 mz-tr4b systemd[1]: Starting Network Manager Script Dispatcher Service...
Sep 05 18:07:41 mz-tr4b systemd[1]: /usr/lib/systemd/system/virtqemud.service:29: Unknown key name 'LimitNOFile' in section 'Service', ignoring.The devices 0000:45:00.0 and 0000:47:00.0 are both ethernet devices so probably network cards.
Not sure if it matters since a bit lower NM reports vnet1 is activated succesfully
There's also this:
Sep 05 18:07:41 mz-tr4b kernel: audit: type=1326 audit(1693924661.803:2): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=15756 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f521ceda0d7 code=0x80000000
Sep 05 18:07:41 mz-tr4b systemd[1]: Started Process Core Dump (PID 15779/UID 0).
Sep 05 18:07:42 mz-tr4b systemd-coredump[15780]: Resource limits disable core dumping for process 15756 (qemu-system-x86).Your vm coredumps but we don't have a clue yet why .
Disable/remove both opengl activating settings and start the VM .
Assuming it starts, use journalctl -b -1 to see the journal of the coredumped boot (use a bigger number to get earlier boot logs) .
If the VM has network access , use command | curl -F 'f:1=<-' ix.io to upload it and post the link that command outputs.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
That's not all I asked for, but it's enough to continue .
Sep 05 18:07:41 mz-tr4b virtnodedevd[8308]: Failed to open a VPD file '/sys/bus/pci/devices/0000:45:00.0/vpd': Operation not permitted Sep 05 18:07:41 mz-tr4b virtnodedevd[8308]: Failed to open a VPD file '/sys/bus/pci/devices/0000:47:00.0/vpd': Operation not permitted Sep 05 18:07:41 mz-tr4b systemd[1]: Starting Network Manager Script Dispatcher Service... Sep 05 18:07:41 mz-tr4b systemd[1]: /usr/lib/systemd/system/virtqemud.service:29: Unknown key name 'LimitNOFile' in section 'Service', ignoring.The devices 0000:45:00.0 and 0000:47:00.0 are both ethernet devices so probably network cards.
Not sure if it matters since a bit lower NM reports vnet1 is activated succesfullyThere's also this:
Sep 05 18:07:41 mz-tr4b kernel: audit: type=1326 audit(1693924661.803:2): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=15756 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=0x7f521ceda0d7 code=0x80000000 Sep 05 18:07:41 mz-tr4b systemd[1]: Started Process Core Dump (PID 15779/UID 0). Sep 05 18:07:42 mz-tr4b systemd-coredump[15780]: Resource limits disable core dumping for process 15756 (qemu-system-x86).Your vm coredumps but we don't have a clue yet why .
Disable/remove both opengl activating settings and start the VM .
Assuming it starts, use journalctl -b -1 to see the journal of the coredumped boot (use a bigger number to get earlier boot logs) .If the VM has network access , use command | curl -F 'f:1=<-' ix.io to upload it and post the link that command outputs.
core dump only happens when run with OpenGL
VM runs normally without active OpenGL in spice
Offline
Please don't quote full posts, only quote parts you are replying to . This improves readability by a lot.
I would very much like to get a journal from one of the coredumped boots. Without it further troubleshooting will be near impossible.
For clarity I will elaborate what I want you to do.
- start the sway vm with "gl enable = yes'
- after it coredumps, remove that setting
- restart the sway vm
the following steps need to be done in the sway guest vm , NOT on the host
- open a terminal
- in the terminal execute as root (or with root-rights)
# journalctl -b -1 | curl -F 'f:1=<-' ix.io - After a short time (could be 30+ seconds depending on your internet upload speed) there will be a link shown in the terminal
post that link.
Edited to improve clarity.
Last edited by Lone_Wolf (2023-09-07 09:30:41)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Offline
Seems further clarification is needed, as that is the journal of the host, added a line to clarify that (also in post #8)
- restart the sway vm
the following steps need to be done in the sway guest vm , NOT on the host
- open a terminal
- in the terminal execute as root (or with root-rights)
# journalctl -b -1 | curl -F 'f:1=<-' ix.io - After a short time (could be 30+ seconds depending on your internet upload speed) there will be a link shown in the terminal
post that link
Last edited by Lone_Wolf (2023-09-07 09:31:25)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Offline
That is a journal from the guest vm, but not one with the coredump in it. Either the coredumped boot is not in the journal, or you need to use another number then -1 to get earlier boots.
There are indications the guest uses a possibly incorrect apparmor setup, but there is something more important :
Sep 07 05:08:04 mz-standardpcq35ich92009 kernel: Linux version 6.1.44-1-MANJARO (builduser@fv-az616-74) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC Wed Aug 9 09:02:26 UTC 2023Your host is running archlinux, but the guest vm is running manjaro.
Unless you switch to an archlinux guest, I can't help further.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I started preparing one archlinux guest. for test
But I think the problem is in the host and never starts with gl
the arch linux guest :
Last edited by maziar (2023-09-07 11:23:45)
Offline
Guest is using llvmpipe and egl has trouble finding a dri screen, but that's not what causes the opengl issues.
I did some research and found info how to enable opengl with a virtio gpu from a qemu command line.
First : Is virglrenderer installed on the host ?
if not, install it.
second : qemu needs a vga card type AND a display type .
The vga type card should be set with -vga virtio .
Note that this may already be satisified by the <video> </video> section of the libvrit xml file.
The display type needs to be set to sdl or gtk with gl=on added, like -display sdl, gl=on .
(Other display types don't support virtio opengl as far as I know).
No idea where in the xml file that last part should go, but virsh supports a method to add qemu cli options to any libvirt VM xml-file.
see https://blog.wikichoon.com/2017/03/easy … -with.html
Once you make those changes, make sure to boot the guest to multi-user.target to avoid issues in the graphical environment.
When the guest gets to console login, login as root and run dmesg | grep drm .
it should show several lines, including something like "virgl 3d acceleration enabled" .
Last edited by Lone_Wolf (2023-09-07 15:27:46)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Guest
First : Is virglrenderer installed on the host ?
Sure installed: ver 0.10.4
Guest is using llvmpipe and egl has trouble finding a dri screen, but that's not what causes the opengl issues.
The vga type card should be set with -vga virtio .
Note that this may already be satisified by the <video> </video> section of the libvrit xml file.The display type needs to be set to sdl or gtk with gl=on added, like -display sdl, gl=on .
(Other display types don't support virtio opengl as far as I know).No idea where in the xml file that last part should go, but virsh supports a method to add qemu cli options to any libvirt VM xml-file.
Also, my research shows that new qemu & virgl & libvirt have compatibility/Documentation problems.
But the real problem is how to fix this with libvirt!. It seems a more complex setting when using Wayland!!
some do similar with https://github.com/dmacvicar/virt-manag … evices.xml
<qemu:commandline xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
<qemu:arg value="-display"/>
<qemu:arg value="gtk,gl=on"/>
<qemu:arg value="-device"/>
<qemu:arg value="vfio-pci,addr=05.0,sysfsdev=/sys/class/mdev_bus/0000:00:02.0/f321853c-c584-4a6b-b99a-3eee22a3919c"/>
<qemu:arg value="-set"/>
<qemu:arg value="device.video0.driver=virtio-vga"/>
<qemu:arg value="-foo"/>
<qemu:arg value="bar"/>
<qemu:env name="DISPLAY" value=":0.1"/>
</qemu:commandline>
</domain>I think all is x11 :
<graphics type="sdl" display=":3.4" xauth="/tmp/.Xauthority"/>
I can not find any document to fix with libvirt with Wayland.....
Last edited by maziar (2023-09-07 16:45:41)
Offline
The role of libvirt / qemu for a guest virtual machine is to provide 'fake' hardware to the OS in the guest.
X, wayland. arcan and other display servers used in the guest are irrelevant to libvirt / qemu.
The -display option for qemu informs qemu how the virtual graphics device in the guest hardware should communicate with the host .
The libvirt project:
is a toolkit to manage virtualization platforms
In other words libvirt is a frontend for multiple virtualization platforms like qemu.
Try what I posted in #14.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
The role of libvirt / qemu for a guest virtual machine is to provide 'fake' hardware to the OS in the guest.
X, wayland. arcan and other display servers used in the guest are irrelevant to libvirt / qemu.The -display option for qemu informs qemu how the virtual graphics device in the guest hardware should communicate with the host .
https://libvirt.org wrote:The libvirt project:
is a toolkit to manage virtualization platforms
In other words libvirt is a frontend for multiple virtualization platforms like qemu.
Try what I posted in #14.
But the question is how to do it.
I try with:
<qemu:commandline>
<qemu:arg value="-display"/>
<qemu:arg value="sdl,gl=on "/>
</qemu:commandline>
get error : sdl,gl=on : Parameter 'gl' does not accept value 'on '
Offline
Qemu does support that commandline option in that way and it's an option that has been around for years.
You did use virt-xml to get those options in the xml-file for the VM ?
Does using -display gtk,gl=on make a difference ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I always edit XML & restart libvirtd service
#18 Display 'gtk' is not available.
Offline
I did some checking of the qemu manpage and there are 5 cases were gl is a sub-paramater for a -display type. All of those do support gl=on .
For clarity :
I always edit XML & restart libvirtd service
You use a commandline like
virt-xml swayvm --edit --confirm --qemu-commandline="-display sdl,gl=on"?
If yes, there appears to be a bug in the parser flibvirt uses for qemu commandline options .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
virt-xml swayvm --edit --confirm --qemu-commandline="-display sdl,gl=on"?
Same error :-(
Offline
You could (and probably should) file a bug with the libvirt project, but that doesn't solve the graphics performance .
Passing through a videocard to the guest looks like best option , but that requires to have 2 or more availalble.
(There are ways to use pci passthrough with a single gpu, but they require additional scripting and no idea how well that works with libvirt .)
I suggest you try the vmware vga type . It is supported by mesa and has a linux kernel module called vmwgfx.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Offline