Plan and objectives
Device | Status | Start date | First Patch release (gerrit) | Expected due date | ||
---|---|---|---|---|---|---|
GPU | ongoing | 2023-07-03 | week 40 | ~End of Oct. 2023 | ||
sound | done | 2023-07-03 | week 41 | ~End of Oct. 2023 | ||
GPIO | done | 2023-08-28 | week 40 | ~End of Oct. 2023 | ||
CAN | done | 2023-10-09 | week 44 | 08/12/2023 | ||
console | ongoingdone | 2023-11-06 | week 51 | end of 2023 | AWS AMI creation | - | end of 2023
cloud task | ongoing | AGL AMM Feb 2024 | ||||
GPU | ongoing | 2023-07-03 | AGL AMM Feb 2024 |
Weekly activity reports
This page contains weekly reports of the Virtual Open Systems activity about the "AGL Native VIRTIO phase 2" project.
week 28
Sync status slides
LF-project-status-2024-01-17.pdf
Console & Can
Follow the PRs' review process and answer to any incoming questions
The PRs can be found in the link below:
- [vhost-device-console](https://github.com/rust-vmm/vhost-device/pull/601)
- [vhost-device-can](https://github.com/rust-vmm/vhost-device/pull/602)
Benchmarks:
We have designed two device agnostic benchmark tests for measuring and comparing latency and throughput between virtio-loopback and "QEMU & vhost-user" cases.
The latency benchmark has been completed and we have already the final results by performing it on a RPI4. Lastly, this week we designed and we are at the process to finalize the implementation of throughput benchmark. Next week, out efforts will be focused to complete the throughput benchmark and start creating a presentation which includes the overall results.
GPU:
The work focused on investigating runtime errors of vhost-user-gpu & virtio-gpu device models on virtio-loopback-adapter. This includes sequences of
virtio-gpu protocol requests of the backend (contrib/vhost-user-gpu) and the actions performed by the virtio-gpu device support on virtio-loopback-adapter.
Such requests are mishandled by adapter's virtio-gpu support resulting in crash/hangup and returning invalid data to the rendering pipeline. Started an effort
to rewire the virtio-gpu model emulation on a QEMU process and let virtio-loopback-adapter handle only the transport path of 'virtqueues' using virtio-loopback.
Next steps include the analysis, resolution of the virtio-gpu device model integration and wiring on virtio-loopback-adapter.
week 27
Console & Can:
One pull request (PR) for each device has been sent to rust-vmm community [github repo](https://github.com/rust-vmm/vhost-device).
The PRs can be found in the link below:
- [vhost-device-console](https://github.com/rust-vmm/vhost-device/pull/601)
- [vhost-device-can](https://github.com/rust-vmm/vhost-device/pull/602)
Next steps are to follow up with the review/comments coming from the community.
GPU:
The work focused on AGL-Yocto integration of vhost-user-gpu support for virtio-loopback, testing the performance of vhost-user-gpu and running the solution on the ARM64 reference-hardware platform.
Created a patch for the virtio-loopback-driver recipe with the necessary kernel configuration options to support the virtio-gpu driver when agl-egvirt feature is enabled. Continued the porting effort of virtio-loopback-adapter vhost-user-gpu support to the Yocto building system and resolved library linking errors on libvirglrenderer.
Next steps include the upstreaming of vhost-user-gpu support on virtio-loopback-adapter that is now in testing phase. Further analysis of the performance of virtio-loopback/virtio-gpu running the Ubigine/Valley benchmark on ARM64 and x86 host machines.
week 26
Console & Console
Finalize the code and start preparing RFCs for rust-vmm community (vhost-device crate).
Next week a pull request for each device will be sent on rust-vmm community [github repo](https://github.com/rust-vmm/vhost-device)
Sound:
This week we focused on cross-compiling issues related to vhost-device-sound. We were able to find the solution for cross-compiling it manually, with the following steps:
Requirements:
- gcc-aarch64-linux-gnu (debian package)
Build process: 1) clone latest repo: git clone https://github.com/rust-vmm/vhost-device 2) Add a new target for cross-compilation: rustup add target aarch64-unknown-linux-gnu 3) navigate into the repo dir: cd vhost-device 4) Export pkg arm64 lib and enable cross-compilation: a) export PKG_CONFIG_PATH=/usr/aarch64-linux-gnu/lib
// The path and name might be different b) export PKG_CONFIG_ALLOW_CROSS=1
5) cross-compile vhost-device-sound bin: RUSTFLAGS="-C linker=aarch64-linux-gnu-gcc" cargo build --bin vhost-device-sound --target=aarch64-unknown-linux-gnu
Next step is now to verify the yocto configuration aiming to match the two.
GPU:
We are now able to run weston and glmark2 applications on top of virtio-loopback vhost-user-gpu using a VM as host system (for development purposes). We are now porting the same environment on the RefHW and we will come back to you next week with numbers.
week 25
gerrit reviews:
Reviews for 29545 and 29539 arrived today and are now merged. I am now rebasing my patches to submit related changes for 29539
sound:
We are working on the vhost-user-sound recipe. However, there is an issue with the rust cross-compilation of the sound device that is preventing us from building it using yocto. We are now investigating to see what's the issue and how to solve it. More info next week.
GPU:
The activity continued on testing 3D workload applications and the glmark2 benchmark. Identified an issue on surfaces shared on newly created file descriptors. Launching a new application, such as the Weston compositor or a 3D workload application, drives the vhost-user-gpu application to create a file-descriptor that is transferred to virito-loopback-adapter via unix-socket. Worked on identifying such cases and modified the adapter to retrieve the data frames from the correct file-descriptor. Collected benchmark data from the QEMU+vhost-user-gpu use case by running the glmark2 benchmark. With the virtio-loopback solution the glmark2 benchmark was not able to successfully execute the whole benchmark.
Following work includes fixes on the virtio-loopback-adapter for correct execution of applications (launching/closing multiple applications)and the execution of the glmark2 benchmark.
week 24
gerrit reviews:
This week we pushed the console device (29545) and we updated 29539. Looking forward to get reviews so that we can proceed with sound and adapter.Console
Review the code and prepare it for an RFC on rust-vmm community for vhost-device crate.
Next step is to create a pull request for each device on vhost-device [github repo](https://github.com/rust-vmm/vhost-device)
Sound:
I had a sync with Yamaguchi-san this week and he mentions being stuck on the fact that AGL crosssdk that does not include cargo tool by default and by consequence he is not able to cross-compile. @Jan-Simon Moeller do you have any hints on this? I'll contact Yamaguchi-san again next week to try to solve the issue.
In addition, this week we focused on design and implementation of benchmarks.
We created a latency benchmark which measures a round trip from vhost-device-sound to virtio-sound and back.
Next steps, is to run this benchmark and compare the results between the following two scenarios:
a) Qemu - vhost-device-sound
b) Virtio-loopback - vhost-device-sound
week 23
gerrit reviews:
virtio-loopback-driver patch to support both qemu-x86 and qemu-arm64 was pushed and merged. Also, a new version of 29407 was prepared and merged. Lastly, we started the integration of console with 29539. The yocto part will come next.
Meta-aws
With the latest virtio-loopback-driver patch that supports both qemu-x86 and qemu-arm64, we are now in line with the execution of virtio-loopback in AWS. We will test the image once Jan-Simon completes the initial support for the AMI creation.
Console & CAN upstreaming
We started preparing a pull request for the vhost-device rust-vmm community which will be ready next week.
Sound:
A new multi-sound device guide is created for Yamaguchi-san to use. It describes all the steps required to reproduce the demo presented during OSS23
GPU:
The work continued on integration testing of the vhost-user-gpu protocol requests. In particular tested the functionality of VHOST_USER_GPU_GET_DISPLAY_INFO, VHOST_USER_GPU_GET_EDID and VHOST_USER_GPU_SCANOUT which are requested by the virtio-gpu driver in order to retrieve and setup the requirements from the display-server side.
The VHOST_USER_GPU_CURSOR_POS/CURSOR_POS_HIDE/CURSOR_UPDATE requests are implemented as dummy functions at this moment. Continued on testing the requests that are carrying the frames-payload from the contrib/vhost-user-gpu application to the virtio-loopback-adapter focused on the VHOST_USER_GPU_UPDATE/DMABUF_UPDATE,VHOST_USER_GPU_SCANOUT and VHOST_USER_GPU_DMABUF_SCANOUT. Successfully tested the acquisition and transfer of DMABUF file-descriptor resources from the vhost-user-gpu application to the adapter.
The following work includes the functional test and benchmark of the vhost-user-gpu support on virtio-loopback-adapter. The benchmark use-case will compare 3D workloads running on virito-loopback and compared with the frame rate achieved by vhost-user-gpu when running with a QEMU VM.
week 22
gerrit reviews:
virtio-loopback-driver patch to support both qemu-x86 and qemu-arm64 was pushed and merged. Also, a new version of 29407 was prepared and merged. Lastly, we started the integration of console with 29539. The yocto part will come next.
Meta-aws
With the latest virtio-loopback-driver patch that supports both qemu-x86 and qemu-arm64, we are now in line with the execution of virtio-loopback in AWS. We will test the image once Jan-Simon completes the initial support for the AMI creation.
Console & CAN upstreaming
We started preparing a pull request for the vhost-device rust-vmm community which will be ready next week.
Sound:
A new multi-sound device guide is created for Yamaguchi-san to use. It describes all the steps required to reproduce the demo presented during OSS23
GPU:
The work continued on integration testing of the vhost-user-gpu protocol requests. In particular tested the functionality of VHOST_USER_GPU_GET_DISPLAY_INFO, VHOST_USER_GPU_GET_EDID and VHOST_USER_GPU_SCANOUT which are requested by the virtio-gpu driver in order to retrieve and setup the requirements from the display-server side.
The VHOST_USER_GPU_CURSOR_POS/CURSOR_POS_HIDE/CURSOR_UPDATE requests are implemented as dummy functions at this moment. Continued on testing the requests that are carrying the frames-payload from the contrib/vhost-user-gpu application to the virtio-loopback-adapter focused on the VHOST_USER_GPU_UPDATE/DMABUF_UPDATE,VHOST_USER_GPU_SCANOUT and VHOST_USER_GPU_DMABUF_SCANOUT. Successfully tested the acquisition and transfer of DMABUF file-descriptor resources from the vhost-user-gpu application to the adapter.
The following work includes the functional test and benchmark of the vhost-user-gpu support on virtio-loopback-adapter. The benchmark use-case will compare 3D workloads running on virito-loopback and compared with the frame rate achieved by vhost-user-gpu when running with a QEMU VM.
week 21
gerrit reviews:
This week we started with a new version of 29407 (rust implementation of GPIO and RNG), adding CAN and addressing comments. Also we produce important patches for the adapter repository (29398 and 29398) and fixes at kernel side (29492) that aims to build both RefHW and qemu x86 targets. The review of the first one is ongoing, while the other three are now merged. Next is new version of 29407 (v4).
AWS task:
We started the investigations of meta-aws to understand where to put our fingers. The idea is to use EC2 AMI creation feature to build a linux image for AWS that contains virtio loopback binaries, drivers and adapter. Let us know if you have any additional comments or requests for this task.
Virtio-Console:
We established a communication between adapter / vhost-user-console backend. During this communication, the two user-space components exchange virtio features, vhost-user features, queue number, queue size, etc. but they do not exchange any data. During the sub-task, we develop vhost-user-console backend in order to define two simple receive/send queues and use this simple setup to exchange messages with the adapter. Also, the serial console is shown in vhost-device-console terminal and we added send/receive functionality code into vhost-user-console and multiport console feature. After the initial communication between adapter and vhost-user-console device, a new virtio-console (/dev/hvc0) device is being inserted successfully into the kernel. At that moment, by using "getty" for this new device ("hvc0"), messages are sent/received through virtio-console, virtio-loopback-transport, adapter, to vhost-user-console device and vice versa. This results in giving the ability to any user to login and have terminal access through vhost-device-console. The virtio-console multiport feature is added and initializes two additional control queues for the exchange of console console messages. Next week we plan to polish the code for finalization.
GPU:
The work focused on the integration of virtio-gpu.c/virtio-gpu-gl.c on the virtio-loopback-adapter and its dependent functions. Tested the SDL2/EGL window creation and frame update functionality using pre-recorder frames. Initial tests showed frame updates when the rendering API 'dpy_gfx_update()' is used. Continued on resolving structure dependencies from QEMU that are not ported to the adapter application. This is done in order to not pull all minor components from QEMU sources. Updated the virtio-gpu cursor event requests to dummy implementations since cursor support is not yet reached/tested.
The next steps are to enable and test the handling of contrib/vhost-user-gpu requests related to the Window instantiation (SDL) and the frames update. Also, test the integration of virtio-gpu/gl devices in regard to the parent vhost-user-gpu device on virtio-loopback-adapter. The use-case testing compositor will be Weston.
week 20
gerrit reviews:
Egvirt feature changes (29408) was merged. Review for 29407 (rust implementation of GPIO, I2C, RNG and VSOCK) is ongoing and I hope it will be merged soon. Next we are going to start the activities to push the CAN device. In the meantime we are working to build the sound recipe (currently dealing with rust dependencies), and will come back to you next week.
...