Hey everyone,
During PTG we discussed about having a centralized place for the buildkite pipeline. The buildkite pipeline is the definition of steps (or commands) that run as part of the CI.
Since all crates will have to pass common tests like `cargo test`, `cargo build` and `cargo fmt` the idea would be to have these steps in a centralized repository so we do not have to duplicate the pipeline in all repositories. I created an issue for this purpose [1]. The pipeline would live in a `…
[View More]buildkite-ci` repository or similar. Maybe rust-vmm-ci is a better option so we can have the coverage test in the same repository as well, but that is a different discussion.
Each GitHub repository would then use `buildkite-ci` as a git submodule. To better explain this, let's take an example.
Let's say we have `buildkite-ci.git` and in it we have a `.buildkite` directory. In the buildkite directory we have `pipeline.yml` which defines steps/commands like cargo build and cargo test.
Now, say we want to enable the buildkite CI for the vm-memory repository. To do that, we would need to do the following:
1. Add `buildlite-ci` as a git submodule of vm-memory.
2. Add a new vm-memory-ci pipeline using the Buildkite web interface.
3. Specify which pipeline to use to run the tests. This is done via a command called "pipeline upload" which takes as a parameter a path that is relative to the root of the repository. You can read more about it here [2]. The command in this case will look something like:
buildkite-agent pipeline upload buildkite-ci/.buidkite/pipeline.yml
With this design you get 2 things:
1. You don't have to duplicate the pipeline for all repositories
2. You can still have custom integration tests for each repository
Now, after some thought I started to believe that the better choice is to actually provide multiple pipelines instead of one. My proposal would be to have one pipeline for each platform and operating system we want to support. And let me tell you why:
1. Some crates (like vm-memory) will also have support for Windows so you want to the integration tests to pass on windows as well. But you can't have it in the default pipeline because some crates cannot have it (like kvm-ioctls).
2. Ideally we would have *most* of the crates work on arm and x86. That means that in our pipelines we would have same tests on x86 and arm as well. But some tools are not available on arm, so the steps are not exactly the same. Examples of things that aren't available (yet) on arm are clippy and kcov. Now, when we start development we might not want to add support from both arm and x86 from the first PR because it might turn out to be very complex and hard to review. So we can start with x86 and only use the x86 pipeline till support for arm is added.
With our current configuration of crates, platforms and operating systems we would end up having 3 pipelines:
- x86_linux_pipeline.yml (used by kvm-ioctls, vm-memory, vmm-sys-utils)
- x86_windows_pipeline.yml (used by vm-memory)
- arm_linux_pipeline.yml (used by kvm-ioctls, vmm-sys-utils)
What do you all think?
Regards,
Andreea
[1] https://github.com/rust-vmm/community/issues/56
[2] https://buildkite.com/docs/pipelines/defining-steps
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.
[View Less]
Hi everyone!
Here are some notes about the PTG meeting that we had in Denver:
Licensing
---------
The dual licensing purpose is to make sure that Apache2 will not
conflict with GPLv2 licensed projects such as QEMU, which could
eventually use rust-vmm. The decision is to move from a dual
MIT+Apache2 proposal to a dual 3-clause BSD+Apache2. 3-clause BSD is
not incompatible with GPLv2, the same way MIT is not incompatible with
GPLv2. But the benefit of having 3-clause BSD instead of MIT is to …
[View More]not
conflict with the Crosvm existing code that uses 3-clause BSD.
CI
--
We currently have Buildkite running on kvm-ioctls crate. Buildkite runs
on x86-64 and aarch64. We need some Windows testing, to test the
abstraction patches proposed by Crowdstrike folks. Cloudbase will
provide the Windows server to run the Windows CI.
Proposal about having a dedicated “test” repo in the rust-vmm
organization. This would allow every crate to rely on this common
“test” repo to centralize the tests.
Also, we talked about creating a “dummy” VMM that would be a superset
VMM since it would pull every rust-vmm crate. This VMM would allow full
integration testing, additionally to the unit tests already running on
each crate.
The CI should rely on top of tree crate on every pull request, as we
want to test the latest master version. Because the CI will ensure that
a pull request is merged only if the CI passes, we can be sure that
master will never be broken. This is the reason why we can safely run
integration tests based on master branch from each crate.
Testing will be slightly different on a “release” pull request because
it will modify the Cargo.toml file to make sure we’re testing the right
version of every crate, before we can give the green light before
publishing.
Release/Crate publishing
------------------------
How will the crates.io publishing be done?
“All at once” vs “each crate can be updated at any time”. Because we
want to keep the CI simple, which means it will always test on top of
tree, we chose to go with “all at once” solution. Releases are cheap,
hence we will bump the versions of every crate every time we want to
update one or more crates.
We took the decision not to have any stable branches on our
repositories. The project is not mature enough to increase the
complexity of having one or more stable branches. With the same idea in
mind, we took the decision not to have any stable releases to
crates.io.
How to publish on crates.io with some human gatekeeping?
We didn’t take a decision regarding this question, but here are the two
discussed approaches:
We would create a bot having a crates.io key stored on Github with a
set of maintainers that can push the button to let the bot do the work.
OR
We would have manual publishing from any maintainer from the set of
maintainers keys.
The concern regarding the bot is about the key which needs to be stored
on Github (security concern about having the key being stolen).
Crosvm/Firecracker consuming rust-vmm crates
--------------------------------------------
Both projects expect to consume crates directly from crates.io, because
this means the crates are mature enough to be consumed.
The criteria for a crate to be published on crates.io is to have proper
documentation, tests, … as documented here:
https://github.com/rust-vmm/community/issues/14#issue-408351841
QEMU’s interest in rust-vmm
---------------------------
QEMU could benefit from low level parts such as vm-memory crate to make
QEMU core parts more secure.
The other aspect is about vhost-user backends, as they should be able
to consume rust-vmm crates to be implemented in Rust, and be reused by
any VMM.
vm-sys-utils
------------
The first PR is ready and waiting for more review from Firecracker
folks. From Crosvm perspective, the PR is alright, but internal
projects (not only about VMM) are using sys-utils too. That’s the
reason why it’s not straightforward to replace their sys-utils crate
with the vm-sys-utils one, as they will have to write a sys-utils
wrapper on top of vm-sys-utils, so that other internal projects can
still consume the right set of utility functions.
Vhost and vhost-user
--------------------
Vhost pull request has been submitted by Gerry and needs to be
reviewed. We didn’t spend time reviewing it during the PTG.
The vhost-user protocol needs to implement the protocol both for the
slave and the master. This way, the master can be consumed from the VMM
side, and the slave can be consumed from any vhost-user daemon
(interesting for any VMM that could directly reuse the vhost-user
backend). In particular, there is some ongoing work from Redhat about
writing a virtiofsd vhost-user daemon in Rust. This should be part of
the rust-vmm project, pulling the vhost-user-protocol.
The remaining question is to determine if the vhost backends, including
vhost-user (hence including the protocol itself) should live under a
single crate?
vm-allocator
------------
We had a discussion about using a vm-allocator crate as a helpful
component to decide about memory ranges (MMIO or PIO) for any memory
region related to a device.
Based on the feedback from Paolo, Alex and Stefan, we need to design
carefully this allocator if we want to be able to support PCI BAR
programming from the firmware or the guest OS. This means we should be
able to handle any sort of PCI reprogramming to update the ranges
chosen by the vm-allocator, since this is how the PCI spec is defined.
Summary of the priorities
-------------------------
We could maintain a list of priorities in an etherpad (or any sort of
public/shared document), and at the end of each week, send the list of
hot topics and priorities to make sure everyone from the community is
on the same page.
Code coverage
-------------
Which tool should we use to control code coverage?
Kcov is one alternative but it seems like it’s not running on aarch64,
which is a blocker since the project wants to support multiple CPU
architectures. Kcov might be the one being picked up as at first, but
we need to investigate for other solutions.
Do we need to gate pull requests based on the coverage result?
The discussion went both ways on this topic, but I think the solution
we agreed upon was to gate based on a code coverage value. Now, an
important point about this value, it is not immutable, and based on the
manual review from the maintainers, we can lower this value if it makes
sense.
For instance, if some new piece of code is being added, it does not
mean that we have to implement test for the sake of keeping the
coverage at the same level. If maintainers, as they are smart people,
realize it makes no sense to test this new piece of code, then the
decision will be made to reduce the threshold.
Linters
-------
Part of the regular CI running on every pull request, we want to run
multiple linters to maintain a good code quality.
Fuzzing
-------
We want some fuzzing on the rust-vmm crates. Now the question is to
identify which one are the most unsafe crates. For instance, being able
to fuzz the virtqueues (part of the virtio crate) should be very
interesting to validate their proper behavior.
Also, fuzzing vhost-user backends when they will be part of the rust-
vmm project will be one very important task if we want to provide
secure backends for any VMM that could reuse them.
Security process
----------------
At some point, the project will run into some nasty bugs considered as
real security threats. In order to anticipate when this day will come,
we should define a clear process on how to limit the impact on the
rust-vmm users, and to describe how to handle this issue (quick fix,
long term plan, etc...).
vmm-vcpu
--------
After a lot of discussions about the feasibility of having a trait for
Vcpu, we came up to the conclusion that without further proof and
justification the trait will provide any benefit, we should simply
split HyperV and KVM into separate packages. The reason is, we don’t
think those two hypervisors have a lot in common, and it might be more
efforts to try to find similarities rather than splitting them into
distincts pieces.
One interesting data point that we would like to look at in the context
of this discussion is about the work that Alessandro has been doing to
port Firecracker on HyperV. Being able to look at his code might be
helpful in understanding the fundamental differences between HyperV and
KVM.
vm-memory
---------
The pull request #10 is splitting the mmap functionality coming from
Linux, and it adds the support for the Windows mmap equivalent. The
code has been acknowledged by everybody as ready to be merged once the
comments about squashing and reworking the commit message will be
addressed.
vm-device
---------
We discussed about the vm-device issue that has been opened for some
time now. Some mentioned that it is important to keep the Bus trait
generic so that any VMM could still reuse it, adapting some wrappers
for devices if necessary.
Based on the comments on the issue, it was pretty confusing where
things will go with this crate, and that’s why we agreed on waiting for
the pull request to be submitted before going further into hypothetical
reviews and comments.
Samuel will take care of submitting the pull request for this.
Community README about rust-vmm goals
-------------------------------------
We listed the main points we wanted to mention on the README from the
community repository. Andreea took the AR to write the documentation
describing the goals and motivation behind the project, based on the
defined skeleton.
We also mentioned that having a github.io webpage for the project would
be a better way to promote the project. We will need to create a
dedicated repo for that, as part of the rust-vmm Github organization.
We will need to put some effort into putting this webpage together at
some point, the first step being to duplicate more or less the content
of the README.
Thanks,
Sebastien
[View Less]
Hi everyone,
In a few days, some contributor teams will meet in Denver for the 5th
Project Teams Gathering. The event is organized around separate 'tracks'
(generally tied to a specific team/group).
Topics of discussion are loosely scheduled in those tracks, based on the
needs of the attendance. This allows to maximize attendee productivity,
but the downside is that it can make the event a bit confusing to
navigate. To mitigate that issue, we are using an IRC bot to expose
what's …
[View More]happening currently at the event at the following page:
http://ptg.openstack.org/ptg.html
It is therefore useful to have a volunteer in each room who makes use of
the PTG bot to communicate what's happening. This is done by joining the
#openstack-ptg IRC channel on Freenode and voicing commands to the bot.
Usage of the bot is of course optional, but in past editions it was
really useful to help attendees successfully navigate this dynamic event.
How to keep attendees informed of what's being discussed in your room
---------------------------------------------------------------------
To indicate what's currently being discussed, you will use the track
name hashtag (found in the "Scheduled tracks" section on the above
page), with the 'now' command:
#TRACK now <what's currently being discussed>
Example:
#swift now brainstorming improvements to the ring
You can also mention other track names to make sure to get people
attention when the topic is transverse:
#ops-meetup now discussing #cinder pain points
There can only be one 'now' entry for a given track at a time. To
indicate what will be discussed next, you can enter one or more 'next'
commands:
#TRACK next <what will be discussed and when>
Example:
#api-sig next at 2pm we'll be discussing pagination woes
Note that in order to keep content current, entering a new 'now' command
for a track will automatically erase any 'next' entry for that track.
Finally, if you want to clear all 'now' and 'next' entries for your
track, you can issue the 'clean' command:
#TRACK clean
Example:
#ironic clean
How to book reservable rooms
----------------------------
Like at every PTG, in Denver we will have additional reservable space
for extra un-scheduled discussions. Two of those rooms (Ballroom 4 and
Room 112) are equipped with a projector, so if your discussion would
benefit from projection, you can also book time there. Finally, some of
the smaller teams do not have any pre-scheduled space, and will solely
be relying on this feature to book the time that makes the most sense
for them. Those teams are the OpenStack release management team
(#release-management) and requirements team (#requirements), the
Extended Maintenance SIG (#extended-maint-sig), the Security SIG
(#security-sig), the Bare Metal SIG (#baremetal-sig) and the
Interoperability working group (#interop-wg).
The PTG bot page shows which track is allocated to which room, as well
as available reservable space, with a slot code (room name - time slot)
that you can use to issue a 'book' command to the PTG bot:
#TRACK book <slot code>
Example:
#release-management book Room 112-ThuA1
Any track can book additional space and time using this system. All
slots are 1h45-long. If your topic of discussion does not fall into an
existing track, it is easy to add a track on the fly. Just ask PTG bot
admins (ttx, diablo_rojo...) on the channel to create a track for you
(which they can do by getting op rights and issuing a ~add <TRACK> command).
For more information on the bot commands, please see:
https://opendev.org/openstack/ptgbot/src/branch/master/README.rst
Let me know if you have any additional questions.
--
Thierry Carrez (ttx)
[View Less]
Hello everyone,
I was working on implementing a generic solution for dealing with kvm structures that contain zero-sized arrays as part of the kvm-ioctls crate. This is the PR: https://github.com/rust-vmm/kvm-ioctls/pull/6 and there has been a suggestion there to have this code in a base rust-vmm crate since the issue is quite common.
I wanted to get your input on creating a rust-vmm/common crate for this. Would anyone have any concerns about this approach ?
Thanks,
Serban
Amazon …
[View More]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.
[View Less]
To anyone interested, the VCPU crate, which provides hypervisor-agnostic
abstractions for VCPU functionality, is up for review here:
https://github.com/rust-vmm/vmm-vcpu/pull/3.
Thanks for any feedback!
Jenny
Hey everyone,
Quick update on kvm-ioctls. I just published v0.1.0 to crates.io [1].
The list of ioctls is not complete (not all ioctls used by CrosVM are added, but that's WIP) [2].
We are also still working on ARM support [3]. Adding coverage test is not really straightforward at the moment and we are refining the unit tests and code examples.
For the full list of TODOs, please check the corresponding issues [4].
Regards,
Andreea
[1] https://crates.io/crates/kvm-ioctls
[2] https://…
[View More]github.com/rust-vmm/kvm-ioctls/issues/11
[3] https://github.com/rust-vmm/kvm-ioctls/issues/8
[2] https://github.com/rust-vmm/kvm-ioctls/issues
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.
[View Less]
Hey everyone,
There are a bunch of PRs opened that would need some attention. Could you please take some time to review them?
Also, if you are one of the people that have submitted a PR, please take some time to respond to comments and update your PRs based on the reviews.
In kvm-ioctls:
- helper functions for altering zero sized array structures (like kvm_cpuid2, kvm_msrs):
https://github.com/rust-vmm/kvm-ioctls/pull/6
- high level documentation for kvm-ioctls (with an x86 example of …
[View More]usage):
https://github.com/rust-vmm/kvm-ioctls/pull/26
- helper function for creating CpuId from kvm_entries:
https://github.com/rust-vmm/kvm-ioctls/pull/29
In vmm-sys-utils:
- Initial PR that adds helpers (this is blocking for adding new crates depending on sys-util)
https://github.com/rust-vmm/vmm-sys-util/pull/1
In vhost:
- Inital PR that adds the vhost code from Firecracker:
https://github.com/rust-vmm/vhost/pull/2
In vm-memory:
- Windows Support:
https://github.com/rust-vmm/vm-memory/pull/10
If you want to be a reviewer for any of them please add yourself as a reviewer. If you don't have permission to do so let me know and I'll fix it.
This list contains all PRs that don't have at least 2 reviewers already. I believe we agreed that the first PR in a repository (the one that essentially adds a lot of code) will be reviewed by at least 3 people coming from 3 different projects to ensure that the crate is usable by all interested parties. For all the others we can fall back to 2 reviews.
What I am trying to avoid here is having same people reviewing all PRs because:
1. It takes some time to do reviews
2. Different people might have different views & find different problems in PRs.
Thanks,
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.
[View Less]
All,
In several cases, we need to generate kernel bindings for some of our
crates (kvm, vhost, virtio), through rust-bindgen.
There's been discussions about whether we should have those bindings as
part of the related crate (e.g. a virtio/src/bindings.rs module for the
virtio bindings) or as a separate crate (virtio-bindings,
vhost-bindings, kvm-bindings).
We (Andreea and myself) believe it makes more sense to have them as
separate crates, and clearly distinguish generated bindings from …
[View More]actual
code consuming them. It generates a few more repos, but that's a minor
burden after all.
Does anyone have strong opinions against that pattern?
Cheers,
Samuel.
---------------------------------------------------------------------
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.
[View Less]
Hi everyone,
It’s time to prepare for the Project Teams Gathering (PTG) that’s co-located with the Open Infrastructure Summit the week of April 29. Both events will take place at the Colorado Convention Center in downtown Denver.
The Rust-VMM community has a dedicated space reserved at the PTG all day, Thurs/Fri, May 2-3.
*ACTION*, we need to start firming up the agenda with discussion topics - https://etherpad.openstack.org/p/rust-vmm-2019-ptg-denver.
If you have not yet registered to …
[View More]attend, please make sure you do before arriving onsite - https://openinfrasummitandptgdenver.eventbrite.com.
The hotel block at the Hyatt Regency still has rooms available, but you must book this week - https://www.hyatt.com/en-US/group-booking/DENCC/G-FNTE.
The Rust-VMM team photo is scheduled for Thursday, May 2, at 4:10pm.
You can view the full list of participating projects on the PTG schedule - https://www.openstack.org/ptg#tab_schedule.
Make sure to check out the Open Infrastructure Summit schedule too - https://www.openstack.org/summit/denver-2019.
Let me know if you have any questions. It’s going to be a fun and productive week!
See you soon,
Claire
[View Less]
Hey,
As per our discussion on this issue https://github.com/rust-vmm/community/issues/14 but also from our last week sync call, we will update the license of existing crates to MIT and Apache-v.2.0 to accommodate both Qemu usecase and Firecracker.
I am currently trying to publish version v0.1.0 of the kvm-ioctls crate to crates.io and before doing so I wanted to also update the license. I lack experience in the licensing domain so I am here to ask (pretty please) if anyone can submit a PR …
[View More]with the updated license or otherwise point me to relevant resources so I can update it myself. I am aiming for publishing the crate either at the end of this week or beginning of the next one. Any takers?
Thanks,
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.
[View Less]