[aarch64][virtio-gpu] KVM_RUN returns EFAULT when running games with Venus
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- linux, rust
- Domain
- computer-graphics, operating-systems
Research direction
Start by reproducing the failure with libkrun 1.19.0, muvm 0.6.0, Venus, and a Steam game under Proton on an aarch64 host, then collect the complete logs offered in the report. Trace the virtio-gpu queue mapping and the KVM_RUN path around the EFAULT failure; done means the affected games run without the VM stopping.
Written by the indexing model from the issue text.
Description
Hi,
Thank you for this amazing project!
I'm seeing a reproducible KVM_RUN failure when running a Steam game through muvm with Venus on an aarch64 host.
My Hardware/software are:
- Ampere Altra Q80-33 (aarch64)
- Intel Arc Pro B60 (Battlemage BMG-G21, 24 GiB)
- Linux 7.2.2
- libkrun 1.19.0
- muvm 0.6.0
- virglrenderer 1.3.0
- Venus + FEX / steam-asahi project
Basic Vulkan works correctly through Venus (vulkaninfo and vkcube).
However, launching a Steam game under Proton reproducibly causes the VM to stop with:
DEBUG krun_devices::virtio::gpu::virtio_gpu] mapping: host_addr=e47ecbb00000, addr=e47ed7880000, size=2097152
DEBUG krun_devices::virtio::gpu::worker] gpu: process_queue exit
ERROR krun_vmm::linux::vstate] Failure during vcpu run: Bad address (os error 14)
DEBUG krun_vmm] using vcpu exit code: 1
INFO krun_vmm] Vmm is stopping.
I reproduced the same Bad address (os error 14) failure with multiple Steam games.
This is reproducible with an unmodified upstream libkrun 1.19.0.
I'm happy to provide complete logs or run additional tests if useful.
- Dominant language
- Rust
- Stars
- 2.8k
- Forks
- 279
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 28
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libkrun/libkrun
-
virtio-fs (Linux passthrough): debug log in do_lookup panics the fs worker on non-UTF-8 file namesPossibly taken @zcl-g5 claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
libkrun/libkrun#895 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 12/100
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 2 days
-
All virtiofs shares return ECONNREFUSED in the guest (macOS host, libkrun 1.19.6 + krunkit 1.3.2)Open
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 2 days
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rescript-lang/rescript#8765 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
chroma-core/chroma#7879 ·
Maintainers usually reply within 1 day
-
priority middle
Difficulty 1/5 Under an hour Newbie friendliness 72/100
KATO-Hiro/AtCoderClans#12838 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day