- Rust-vmm - lists.opendev.org

Project gate keeping
by Samuel Ortiz 12 Jun '19

12 Jun '19

All, As discussed during last week's call, I'd like to propose a light process for PR reviews and gate keeping. At the moment, when a PR lands in any of the existing crates, no one gets assigned to review it and we're asking for 2 review approvals before merging it. Those approvals should come from members of the crate's "team", and we need to arbitrarily build those teams on the fly based on the crate activity and contributions. As the number of incoming PRs is increasing, I feel we're starting to see some limitations with the above described model. While many PRs get actively reviewed, others slightly less. Also, pinging people for reviews and approvals is handled manually at the moment. In order to improve that situation, here is my proposal: - Have a team of 8-10 rust-vmm gatekeepers. 2 randomly selected gatekeepers will be automatically assigned to any incoming PR. - Any gate keeper is free to assign someone else from the gate keeper team if she/he does not have the badwidth/knowledge to review the PR. - Encourage CODEOWNERS[1] file additions. Not all repos may need such ownership so I don't think this should be mandatory. - Any PR will be mergeable when any of the below conditions are met: * When a repo has a CODEOWNERS file, 1 code owner and 1 gate keeper approved it. * On CODEOWNERS-less repos, 2 gate keepers approved it. - Initial PRs for empty crates could be handled differently and informally require more approvals from different people. I guess the natural question coming next is who should be part of this gate keeper team. rust-vmm being almost 6 months old, I think we now have a good idea of who are the most active contributors to the project. And I think it's logical to build this initial gate keepers team from those initial active contributors: Andreea Florescu @andreeaflorescu Alexandru Agache @alexandruag Alexandra Iordache @aghecenco Jiang Liu @jiangliu Paolo Bonzini @bonzini Zach Reizner @zachreizner Jenny Mankin @jennymankin Sebastien Boeuf @sboeuf Rob Bradford @rbradford Samuel Ortiz @sameo Comments, disagreements, additions, etc are all very welcome. Cheers, Samuel. [1] https://help.github.com/en/articles/about-code-owners --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

4 7

rust-vmm CI
by Florescu, Andreea 06 Jun '19

06 Jun '19

Hey everyone, A while ago we discussed about having a centralized placed for Buildkite pipelines and other integration tests that can be run for all repositories in rust-vmm [1]. For this scope I opened PR in rust-vmm-ci that contains: - a Buildkite pipeline with tests that can be run for all crates. The only pipeline there is the Linux one, but we will also add the Windows pipeline. In the meantime we can test vm-memory using the windows pipeline defined in the repository. - test_coverage.py: test to check that coverage does when merging new PRs The point of having one place with all common tests is to ensure that we keep the same quality standard across all crates in rust-vmm. It also avoids duplicating the same tests and pipelines across multiple repositories. It should make adding a CI for a new repository easier in the future. The mechanism I chose for using the same Buildkite pipeline in all repository is git submodules. More details about why I chose this approach can be found in the initial issue[1]. Let me know what you think on these 2 PRs: 1. rust-vmm-ci PR with the pipeline and integration tests [2] 2. kvm-ioctls PR that adds rust-vmm-ci as a git submodule [3]. Regards, Andreea [1] https://github.com/rust-vmm/community/issues/56 [2] https://github.com/rust-vmm/rust-vmm-ci/pull/2 [3] https://github.com/rust-vmm/kvm-ioctls/pull/48 Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

1 0

CFPs Open June-July
by Claire Massey 30 May '19

30 May '19

Hi everyone, Several CFPs are open for events later this year. If you submit any Rust-VMM talks to these or other events please let the group know so we can coordinate. Listed in order by CFP deadline: * 6/15 - KVM Forum in Lyon Oct 30 - Nov 1 - https://events.linuxfoundation.org/events/kvm-forum-2019/ <https://events.linuxfoundation.org/events/kvm-forum-2019/> * 6/16 - ONS in Antwerp Sept 23-25 - https://events.linuxfoundation.org/events/open-networking-summit-europe-201… <https://events.linuxfoundation.org/events/open-networking-summit-europe-201…> * 6/22 - OpenInfra Days Nordics in Stockholm Oct 2-3 - https://openinfranordics.com/ <https://openinfranordics.com/> * 7/2 - Open Infrastructure Summit in Shanghai Nov 4-6 - https://cfp.openstack.org/ <https://cfp.openstack.org/> * 7/12 - KubeCon/CloudNativeCon NA in San Diego Nov 18-21 https://linuxfoundation.smapply.io/prog/kccncna2019/ <https://linuxfoundation.smapply.io/prog/kccncna2019/> Thanks, Claire

3 2

vm-memory Pull Requests
by Florescu, Andreea 30 May '19

30 May '19

Hey everyone, In case you are not following the Slack channel: we are now using Buildkite as the official CI for the vm-memory crate. We changed Travis with Buildkite as the vm-memory is also expected to work on Windows and doing the checks with Travis was not straightforward. Anyway, if you have PRs open, please rebase them on top of the latest commit and fix the errors (if any). Regards, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

2 1

Organization membership
by Samuel Ortiz 29 May '19

29 May '19

All, The community README has a "Become a member of rust-vmm" section [1] describing how to open an issue for being added as a member of the rust-vmm organization. This seems to imply that organization members have special privileges or even worse, that one needs to be an organization member to contribute to the project. We want to remove that perception because a) members do not have any special permissions on the organization and b) any registered github user can contribute to the project. So we want to remove that section and the associated issue template. Any objections? Cheers, Samuel. [1] https://github.com/rust-vmm/community#become-a-member-of-rust-vmm --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 2

Reminder, May 29 Meeting
by Claire Massey 28 May '19

28 May '19

Hi everyone, It’s been a while - so friendly reminder - there will be a Rust-VMM community call tomorrow, Wednesday, May 29 at 8:00am PST. Please add agenda topics here: https://etherpad.openstack.org/p/rust_vmm_2019_biweekly_calls <https://etherpad.openstack.org/p/rust_vmm_2019_biweekly_calls>. Dial in info: https://zoom.us/j/181523033 One tap mobile +16699006833,,181523033# US (San Jose) +16468769923,,181523033# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) Meeting ID: 181 523 033 Find your local number: https://zoom.us/u/abOe7d3zx9 Thanks, Claire

1 0

Rust OSDev
by Florescu, Andreea 22 May '19

22 May '19

FYI I just discovered the Rust OSDev organization on GitHub and from a first look it seems there is some overlap with what we are trying to do. I am specifically referring to the following repositories: - ACPI: https://github.com/rust-osdev/acpi - x86_64 looks like it can have some shared functionality with what we want to do in our arch crate: https://github.com/rust-osdev/x86_64 There might be parts of other repositories that could be interesting for us as well. I will take some time to look at what they are doing and see if we can share something so we don't end up re-invent the wheel. I will share what I discover with you. Regards, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

5 4

rust-vmm review status
by Florescu, Andreea 20 May '19

20 May '19

Hey everyone, Guess who's behind on PR reviews? We aaaare!!! There are some issues and PRs that would need our attention. Well actually now that I got to go through all of them: there are **a lot** of issues and PRs. Please assign yourselves as reviewers so we can move these forward. If you have a PR and you don't receive any reviews in a timely fashion you can just bug individuals to review your code. That worked for me in the past. PRs needing review: 1. Adding initial code for vm-virtio: https://github.com/rust-vmm/vm-virtio/pull/1 2. volatile_memory: add VolatileArrayRef in vm-memory: https://github.com/rust-vmm/vm-memory/pull/19 3. Adding virtio-bindings: https://github.com/rust-vmm/virtio-bindings/pull/1 4. Initial code for the linux-loader: https://github.com/rust-vmm/linux-loader/pull/2 5. Fix warnings on kvm-ioctls: https://github.com/rust-vmm/kvm-ioctls/pull/37 6. More aarch64 specific testing and code on kvm-ioctls: https://github.com/rust-vmm/kvm-ioctls/pull/33 7. Container that is running our current CI with buildkite: https://github.com/rust-vmm/rust-vmm-container/pull/1 8. Initial vhost code: https://github.com/rust-vmm/vhost/pull/2 PRs needing attention from submitter: 1. vm-memory: https://github.com/rust-vmm/vm-memory/pull/9 Issues for creating new crates: 1. ACPI: https://github.com/rust-vmm/community/issues/23 2. Hypervisor-firmware: https://github.com/rust-vmm/community/issues/29 3. cpu-model: https://github.com/rust-vmm/community/issues/31 4. non-volatile memory (nvdimm): https://github.com/rust-vmm/community/issues/38 5. arch: https://github.com/rust-vmm/community/issues/41 6. Hypervisor crate: https://github.com/rust-vmm/community/issues/50 7. Replace kvm-ioctls with kvm: https://github.com/rust-vmm/community/issues/55 8. rust-vmm-ci: https://github.com/rust-vmm/community/issues/56 9. vfio: https://github.com/rust-vmm/community/issues/57 Also, I missed the last sync call, can someone brief me in regarding the vmm-vcpu crate? Regards, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

1 0

Including a virtio-bindings crate in rust-vmm
by Sergio Lopez 19 May '19

19 May '19

Hi, I think it'd be useful having a crate providing virtio bindgen-generated bindings, similar to Firecracker's virtio_gen. I wrote one that provides the same functionality, but with multiple versions mapped as features, as kvm-bindings does: https://git.sinrega.org/slp/virtio-bindings Do you think we could make this a project under rust-vmm's umbrella? Thanks, Sergio.

6 8

Announcing Cloud Hypervisor project
by Rob Bradford 15 May '19

15 May '19

Hi all, Today we released our effort on building a hypervisor based on Rust-VMM components. https://github.com/intel/cloud-hypervisor Cloud Hypervisor makes extensive use of Rust-VMM crates, both released and under development. Thank you to everyone in this community for all your hard work and particularly the crosvm and Firecracker developers whose code provides the basis for most of these crates and is essential in this project. The README has a great explanation of the goals of the project but one that I want to highlight here is the goal to provide a vehicle for the integration of Rust-VMM crates under development and so we are looking forward to many new Rust-VMM crates appearing. Cheers, Rob

2 1