Fix miscellaneous small annoyances

[valpackett]

while using muvm for other use cases. See commit messages.

[slp]

LGTM, thanks @valpackett

[WhatAmISupposedToPutHere]

Should probably also kill x11 forwarding in this case, it is aarch64 only. (Or fix it to work on x86 too, shouldn't be that hard)

[valpackett]

Huh, what's broken about it? I'll test it..

[WhatAmISupposedToPutHere]

https://github.com/AsahiLinux/muvm/blob/main/crates/muvm/src/guest/bridge/x11.rs#L640 - the entirety of RemoteCaller is aarch64 specific

[WhatAmISupposedToPutHere]

So, should do something like this: https://gist.github.com/WhatAmISupposedToPutHere/3b51d4266ca5d7b75f0571adafba031a

(build tested on x86 only, may or may not work)

[valpackett]

Do you have a particular test case that triggers the ptrace code path? I've tried launching a bunch of stuff and it never got triggered:

[WhatAmISupposedToPutHere]

Delete this line, it should force it to use the ptrace method: https://github.com/AsahiLinux/muvm/blob/main/crates/muvm/src/guest/x11.rs#L24

[valpackett]

OK, now I do see my debug prints!

SYSC [9]
[user_regs_struct { r15: 657918200, r14: 0, r13: 0, r12: 140733902978120, rbp: 140733902978080, rbx: 657918176, r11: 582, r10: 17, r9: 0, r8: 9, rax: 9, rcx: 140671840240701, rdx: 3, rsi: 4096, rdi: 140671841247232, orig_rax: 7, rip: 140671848946042, cs: 51, eflags: 582, rsp: 140733902978048, ss: 43, fs_base: 140671842342720, gs_base: 0, ds: 0, es: 0, fs: 0, gs: 0 }]
SYSC [140671841247232]
[user_regs_struct { r15: 657918200, r14: 0, r13: 0, r12: 140733902978120, rbp: 140733902978080, rbx: 657918176, r11: 582, r10: 0, r9: 0, r8: 0, rax: 11, rcx: 140671840240701, rdx: 0, rsi: 4096, rdi: 140671783059456, orig_rax: 7, rip: 140671848946042, cs: 51, eflags: 582, rsp: 140733902978048, ss: 43, fs_base: 140671842342720, gs_base: 0, ds: 0, es: 0, fs: 0, gs: 0 }]
SYSC [0]

during initialization/resizing of GPU programs, and it still works fine \o/

[adilahmad17]

Hi folks! Sorry for budging in, especially if this may be the incorrect place to raise this issue. I thought I would leave a comment in case it is helpful.

I was testing this patch on an amdgpu x86_64 system. Here's a general overview of steps I took:

• Compiled virglrenderer. Did this primarily to enable DRM native context for amdgpu_experimental, but I also enabled the resource mapping patch from Sergio (#1374)
• Compiled libkrun with all the settings enabled
• Compiled muvm using this patch and the config_cli patch (#195)

The good news is that the muvm boots up perfectly and can detect the virtio_gpu device.

[    0.365114] [drm] Host memory window: 0xd00000000 +0xfa5700000
[    0.365117] [drm] features: +virgl +edid +resource_blob +host_visible -fence_passing
[    0.365118] [drm] features: +context_init
[    0.365208] [drm] KMS disabled
[    0.365210] [drm] number of cap sets: 5
[    0.619823] [drm] cap set 0: id 1, max-version 1, max-size 308
[    0.620127] [drm] cap set 1: id 2, max-version 2, max-size 1408
[    0.620386] [drm] cap set 2: id 4, max-version 0, max-size 160
[    0.620567] [drm] cap set 3: id 6, max-version 0, max-size 592
[    0.620833] [drm] cap set 4: id 5, max-version 0, max-size 16
[    0.621101] [drm] Initialized virtio_gpu 0.1.0 for virtio-mmio.3 on minor 0

However, when I tried running glxgears to check performance, I faced the following errors:

> vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
[ 1033.230011] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response 0x1200 (command 0x200)
glx: failed to create dri3 screen
failed to load driver: virtio_gpu
[ 1033.232291] [drm:virtio_gpu_dequeue_ctrl_func] *ERROR* response 0x1200 (command 0x201)
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
5226 frames in 5.0 seconds = 1045.061 FPS
5247 frames in 5.0 seconds = 1049.230 FPS

Basically, it works and the screen shows up, but the driver produces a failure message. The performance is also far lower than the GPU capabilities and the performance I get on Asahi Fedora; the system is using software rendering (irrespective of whether I select "venus" or "drm" as GPU is my guess).

I have not had the time to fully test what is going on, but I will try to do so over the weekend.

[valpackett]

@adilahmad17 what version of Mesa are you using in the vm? Your Mesa should be compiled with the amdgpu-virtio option, that's still not default. For Vulkan it also needs to include commit 7f556805 which is only in main for now.

Venus doesn't provide OpenGL by itself so glxgears wouldn't just work. You need to set MESA_LOADER_DRIVER_OVERRIDE=zink to get GL over Vulkan in that case. (in #195 I asked about whether muvm should just set that by default.. probably yes though)

[adilahmad17]

Thanks a bunch, @valpackett! Mesa was indeed the issue; I was running the latest at this time on Arch 25.2.3-arch and I was under the false impression that amdgpu-virtio would be enabled by default.

I recompiled the main branch of mesa using the following options (left here if someone else wants to follow):

meson setup build -Dgallium-drivers=radeonsi,virgl,llvmpipe,softpipe,zink -Dvulkan-drivers=amd,virtio -Damdgpu-virtio=true -Dtools=zink -Dbuildtype=release

(Note for anyone following the above, check this gist to ensure your application inside the VM is using the custom mesa)

I now see the correct glxinfo; previous one was indeed software all around (llvmpipe):

direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    ... 
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.3.0-devel (git-86557cace1)

Performance is also much closer to native with drm (although still lower but within expected ranges):

> ./test-gears-with-custom-mesa.sh
ATTENTION: default value of option vblank_mode overridden by environment.
64449 frames in 5.0 seconds = 12889.728 FPS

I also tested Venus (--gpu-mode venus). On that option, it seems to default to zink for OpenGL even without the override flag (MESA_LOADER_DRIVER_OVERRIDE), although it hangs at the end. I believe you also noticed the same issue.

> glxinfo -B
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa (0x1002)
    Device: zink Vulkan 1.4 (Virtio-GPU Venus 
    ... 
    (hangs at the end)

I was unable to get glxgears working with the override flag. This seems to also be some mesa driver issues (perhaps with my compilation options).

> ./test-gears-with-custom-mesa-plus-override.sh
MESA: error: vdrm_device_connect failed
radv/amdgpu: failed to initialize device.
MESA: error: ZINK: vkEnumeratePhysicalDevices failed (VK_ERROR_INITIALIZATION_FAILED)
MESA: error: ZINK: failed to choose pdev
glx: failed to create drisw screen
failed to load driver: zink
Error: couldn't get an RGB, Double-buffered visual

Happy to do more testing or write-up a short README based on all the steps I followed. muvm has lots of cool use-cases and the x86_64 support will be very valuable. Thanks for this PR!

[slp]

LGTM. Any concerns @teohhanhui and @WhatAmISupposedToPutHere ?

[slp]

@valpackett please address the clippy issue so we can merge this one. Thanks!

[valpackett]

done!

[slp]

@teohhanhui I see you requested changes to this PR, could you please take another look?

[slp]

Is this one ready for another review?

[valpackett]

Sorry, hadn't noticed the last @teohhanhui review until your comment @slp. Now did the get_var_if_exists refactoring. Definitely ready now!

[valpackett]

Applied all the string changes.

[slp]

@teohhanhui do you thing this one is ready for merging?

[valpackett]

Applied all suggestions and rebased

[slp]

@teohhanhui PTAAL.

[jakogut]

I've tested this on my hardware with the amdgpu driver, works great!