From 3e4c5a6261770bced301b5e74233e7866166ea5b Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Sun, 1 Jun 2025 21:35:14 +0200 Subject: clean up repository --- gitlab/issues_text/target_missing/host_missing/accel_missing/2929 | 7 ------- 1 file changed, 7 deletions(-) delete mode 100644 gitlab/issues_text/target_missing/host_missing/accel_missing/2929 (limited to 'gitlab/issues_text/target_missing/host_missing/accel_missing/2929') diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/2929 b/gitlab/issues_text/target_missing/host_missing/accel_missing/2929 deleted file mode 100644 index 44fca4195..000000000 --- a/gitlab/issues_text/target_missing/host_missing/accel_missing/2929 +++ /dev/null @@ -1,7 +0,0 @@ -Ask to extend vhost-user protocol to carry implementation defined error contexts -Additional information: -I am working on the Google [crosvm](https://chromium.googlesource.com/crosvm/crosvm/) project, which implements some `vhost-user` clients/servers defined by [this QEMU doc](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html). I am wondering if we could add a protocol feature/protocol header flag bit to allow the payload of the reply to carry detailed implementation defined error contexts? - -Specifically, I am working on the `vhost-user-gpu` device, which needs to send some memory mapping request to the frontend(the main process where VCPU lives), so that we can map some GPU memory to the guest. We are trying to diagnose a bug where the frontend can sometimes fail to perform the operation. However, we don't have access to the logs on the main process, so we are left with only very limited information on the `vhost-user-gpu` process. It could be helpful if we could send detailed implementation defined error contexts in the payload of the reply. - -I am wondering in order for the upstream QEMU to accept such "spec" change to the `vhost-user` protocol, what the process should be like? Thanks. -- cgit 1.4.1