- Rust-vmm - lists.opendev.org

Formal Verification for rust-vmm
by Patrick Roy 13 Dec '24

13 Dec '24

Hey all, I hope everyone had a nice weekend (and those of you attending LPC and KVM Forum I hope had nice conferences! I definitely enjoyed meeting some rust-vmm community members at LPC :) This e-mail is born from some discussions about formal verification Matias, Stefano and me had at LPC last week. Matias held a session titled "Verifying the Conformance of a VirtIO Driver to the VirtIO Specification" [1], which touched on rust-vmm's virtio stack, and I have done similar work for Firecracker's virtio stack [3] using the Kani Rust verifier [2]. We also had an intern at AWS in the Kani team work on some formal verification in vmm-sys-util recently [4]. Since there seems to be quite some interest in introducing formal methods to rust-vmm, I thought we could talk about it at the next community sync meeting next Monday (4pm BST, as always)? :D Best, Patrick [1]: https://lpc.events/event/18/contributions/1897/ [2]: https://github.com/model-checking/kani/ [3]: https://github.com/firecracker-microvm/firecracker/blob/4bbbec06ee0d529add0… [4]: https://github.com/rust-vmm/vmm-sys-util/pull/227

4 5

Trying out virtiofsd and vhost-device-sound with UML
by Benjamin Berg 08 Nov '24

08 Nov '24

Hi, so, I was a bit curious about trying out to use virtio devices with UML. virtiofsd is obviously interesting, but I also tried vhost-device- sound (not that I expect anyone actually wants sound). Anyway, I needed some fixes to make it work, see https://lore.kernel.org/linux-um/20241103212854.1436046-1-benjamin@sipsolut… Two of these related to the Rust implementation: 1. The code for VHOST_USER_SET_MEM_TABLE does not accept the message if it is larger than expected. 2. The VHOST_USER_SET_VRING_NUM call for vhost-device-sound seems to have an artificial limit for the queue length of 64. For 1. the fix is easy, we can just send the correct message. However, 2. is more problematic. It does not look like there is a way to discover the limit that vhost-device-sound is enforcing. That means we would be stuck with a hard-coding a limit based on the device type ID, which does not seem like a good idea. Could the limit be lifted in the implementation? Am I maybe missing something and it is possible to discover the limit somehow? Benjamin

2 3

[Call for Presentations] FOSDEM 2025: Virt & IaaS devroom
by Kashyap Chamarthy 31 Oct '24

31 Oct '24

(Cross-posted to KVM, Rust-VMM, QEMU, and libvirt lists.) Hi, The CFP for the 'Virt & IaaS' (Infrastructure as a Service) 2025 "devroom" is out[+]. - Where? — Brussels, Belgium - When? — 02 Feb (Sunday) 2025 - Talk submission deadline — 01 Dec 2024 (The CFP submission on the FOSDEM list[+] says 08 Dec 2024 is the submission deadline in its intro paragraph. But I clarified it with Piotr Kliczewski, the deddline is *01* Dec 2024 and _not_ 08th Dec; I updated it below.) ======================================================================== This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by December *1st* 2024. Important Dates --------------- Submission deadline: 1st December 2024 Acceptance notifications: 10th December 2024 Final schedule announcement: 15th December 2024 Devroom: 2nd February 2025 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pretalx event planning site[1]. It is a new submission system so you will need to create an account. If you submitted proposals for FOSDEM in previous years, you won’t be able to use your existing account. During submission please make sure to select Virtualization and Cloud infrastructure from the Track list. Please provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM[3], we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://fosdem.org/submit [2] virtualization-devroom-manager at fosdem.org [3] https://fosdem.org/2025/practical/conduct/ ======================================================================== [+] https://lists.fosdem.org/pipermail/fosdem/2024q4/003574.html -- /kashyap

1 0

Consider using rustix instead of libc
by John Nunley 28 Jul '24

28 Jul '24

Hello, I originally filed this as an issue on vmm-sys-util, but a maintainer said that this mailing list would be a better audience. `rustix` is a library that aims to provide a safe system interface over the POSIX API, similar to what this crate accomplishes. However, `rustix` excels by using Linux's raw system call interface rather than `libc`, which provides a decent code size and performance benefit. It uses `libc` on non-Linux platforms and can be optionally configured to swap to a `libc`-based backend if desired. I see two options here: - Rewrite `vmm-sys-util` to use `rustix` instead of `libc`. This would be a breaking change in this `vmm-sys-util`, as some parts export `libc` in their public API. - Rewrite higher level crates to use `rustix` instead of `vmm-sys-util`. Which option would be preferred by `rust-vmm`? rustix git repo: https://github.com/bytecodealliance/rustix Best, John Nunley

1 0

Re: [Discussion] rust-vmm RISC-V CI
by Patrick Roy 11 Jul '24

11 Jul '24

Hi! Thanks for reaching out, and sorry for taking a while to get back to you! We talked about this briefly in the community sync on Monday, and think the the approach of "cross-compile on x86 host and run inside QEMU" is viable, although we probably need more than what qemu-user-static has to offer if we want to have the CI test riscv64 support in crates such as kvm-ioctls. There were also some concerns around stability of CI artifacts (e.g. qemu rootfs and guest kernels) for riscv64, but as long as there's people willing to maintain and fix things if they break, that should not be a blocker :) Maybe we can discuss at the next rust-vmm community meeting? The bridge is https://meetpad.opendev.org/rust-vmm-sync, and we meet every second Monday at 4pm BST (3pm UTC). The next meeting is on July 22nd 2024. Best, Patrick On 7/5/24 10:57, 何若轻 wrote: > *CAUTION*: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > Dear Maintainers: > > > Hi! > > > Sorry to bother you on weekends. I'm from ISCAS (Institute of Software Chinese Academy of Sciences), currently working on supporting rust-vmm crates on RISC-V architecture. > > > We would like to offer resources needed for enabling RISC-V CIs, such as x86_64 servers (EPYC 7763) to run RISC-V virtual machines (through QEMU). Because at this stage, SoCs with H extension and ssaia cpu feature, AIA are yet visible on the market. So I'm proposing we use long running and stable QEMU RISC-V virtual machines to do CIs at this period. This is merely my proposal, if you have any request or idea, please let me know. > > > I wonder how much resources, like how many QEMU RISC-V VMs, and the preset of each VMs are required to achieve this. We would be cooperative to make this happen. If you have any demand/request/suggestions, feel free to tell me. Much appreciated! > > > Best regards, > > Ruoqing He (GitHub ID: TimePrinciple) > >

2 1

Jonathan stepping down as a rust-vmm maintainer & On-boarding a new maintainer
by Woollett-Light, Jonathan 22 May '24

22 May '24

Hi guys, From the 31st of May I decided to step down as a rust-vmm maintainer and gatekeeper. To smooth the transition of the activities I have followed this year, Patrick Roy and myself have identified Egor Lazarchuk (https://github.com/ShadowCurse) as a candidate to onboard as maintainer of the crates I am currently responsible for. Egor has previously contributed to rust-vmm with work in kvm-ioctls (#223), vhost (#218), rust-vmm-container (#98) and rust-vmm-ci (#149 and the follow-ups #150 and #151). The next steps will follow the guidelines for on-boarding a maintainer. Egor will post PRs to add himself as a code owner to linux-loader, rust-vmm-ci, vmm-sys-util, vm-superio, rust-vmm-container, vm-allocator, kvm-ioctls and event-manager. If there are any concerns feel free to bring these up in slack, the sync meeting or on the PRs directly. I wish the best for rust-vmm moving forward and will miss helping smooth the rough edges. I’ll still be on slack if you need to contact me. Best regards, Jonathan Woollett-Light

1 0

PTG April 2024 Team Signup Deadline Approaching!
by Kendall Nelson 11 Feb '24

11 Feb '24

Hello Everyone, This is your *last call *to sign up your team up for the next Project Teams Gathering (PTG)[1], which will be held from Monday, April 8 to Friday, April 12 2024! If you haven't already done so and your team is interested in participating, *you need to complete the survey[2] by February 18, 2024 at 7:00 UTC*. Thanks! -Kendall Nelson (diablo_rojo) [1] PTG Site: https://openinfra.dev/ptg/ [2] Team Survey: https://openinfrafoundation.formstack.com/forms/april2024_ptg_survey

1 0

rust-vmm sync meeting
by Florescu, Andreea 30 Jan '24

30 Jan '24

This is the rust-vmm bi-weekly sync meetings. The agenda is flexible, please add topics in the Meeting Notes document (linked below) before the meeting. Meeting Notes: https://etherpad.opendev.org/p/rust-vmm_sync_meeting ==============Conference Bridge Information============== https://meetpad.opendev.org/rust-vmm-sync

2 1

[Call for Proposals] Moving to another video conferencing app for the rust-vmm sync meeting
by Florescu, Andreea 30 Jan '24

30 Jan '24

Hey, For the past years we've been using Chime for the rust-vmm sync meeting. Chime recently added a change by which people need to be explicitly allowed to enter the meeting while the meeting is ongoing. This is inconvenient and we didn't find a way to disable it. As such, we would like to switch to another application for the sync meeting. A few features that were useful with Chime and we should probably make sure other clients also support: - possibility to use it from the browser; we shouldn't force people to install (yet another) app for the rust-vmm sync meeting - support for Linux/Mac/Windows - share screen capabilities Anything else that you think it might be useful? Please add your proposals and requirements here: https://etherpad.opendev.org/p/Videoconferencing_App_for_rust-vmm_sync_meet… Once we gather options, we can vote for the preferred application. Add your requirements and proposals by 22 January 2024. Once we have the requirements & proposals, we will make a poll to decide on the app to use by 29 January 2024. Thanks, Andreea

5 6

rust-vmm sync meeting
by Florescu, Andreea 30 Jan '24

30 Jan '24

This is the rust-vmm bi-weekly sync meetings. The agenda is flexible, please add topics in the Meeting Notes document (linked below) before the meeting. Meeting Notes: https://etherpad.opendev.org/p/rust-vmm_sync_meeting ==============Conference Bridge Information============== https://meetpad.opendev.org/rust-vmm-sync

1 0