March 2019 - Rust-vmm - lists.opendev.org

Rust-VMM Logo Concepts
by James Cole 27 Jun '19

27 Jun '19

Greetings Rust-VMM Team, My name is James Cole and I’m a Graphic Designer with the OpenStack Foundation. We’ve been working on some logo concepts for Rust-VMM and wanted to share them with you. I’ve attached a PDF to this message, or you can view the document online here <https://www.dropbox.com/s/lurra2cyi6nfua9/Rust-VMM_LogoConcepts_R1.pdf?dl=0>. From your earlier brainstorm, it looked like a popular visual concept centered around the use of an epicyclic gear to illustrate the idea of systems within a system. Page 1 of the PDF shows a few examples of epicyclic gears from around the web and Page 2 shows a simplified epicyclic gear we created in a triangular configuration. Page 3 shows some of the more illustratively complex ideas for icons, although you’ll noticed detail can get lost at small sizes. Page 4 shows some additional variations and configurations of the triangular epicyclic gear idea. Pages 5 and 6 are mostly there to show how some of the icons can work beside the name, although we haven’t really dug into typography yet. I’d love to get your thoughts on this stuff and see if you’d be interested in pursuing any of these ideas further. I’ll be checking this thread for your feedback over the next few days before making changes or exploring more colors and typography. Thanks! Looking forward to hearing what you think! James Cole Graphic Designer OpenStack Foundation

15 25

rust-vmm CI & container
by Florescu, Andreea 28 Mar '19

28 Mar '19

Hey, I had two follow-ups from our last sync meeting and I finally got some time to write them up. 1. CI solution for rust-vmm crates The need for a different CI solution (other than Travis) comes from the need of running on bare metal instances for things like performance testing, tests that require access to /dev/kvm, others? I played a bit with buildkite [1] and I found it pretty easy to use. I did some experiments on my fork of the kvm-ioctls crate. You can find an example of the output here [2]. Some things that would make it a good for our scenario are the following: - Integration with GitHub Webhooks. This helps in setting status checks for PRs. - The test are run by a buildkite-agent. The agent can be installed on any machine and has support for many distributions. More details about agents here [3]. This is useful because we can have same tests running on different platforms (arm, x86, some other ancient platform that I never heard about before) and different operating systems (linux, windows, mac, others). - The tests can be defined through a yaml file [4] so we define the tests once and then we can use them for multiple crates. - It is easy to use and has support for organizations & teams. We can create a rust-vmm team on buildkite and multiple people can access and update the CI pipeline. - Support for ignoring redundant pushes. If you do 5 pushes to the same branch, Buildkite will only test the last push. 2. Container for rust-vmm dependencies I assume that most crates will need the same dependencies for running the tests so I created a container for easy handling of the dependencies. I propose to add the container to a rust-vmm repository. More details in the issue [5], please let me know what you think. I would like to setup the CI in the near future (next week maybe?) so we can start testing the kvm-ioctls crate as well. If you have any questions about buildkite let me know. Regards, Andreea [1] https://buildkite.com/ [2] https://buildkite.com/rust-vmm/kvm-ioctls-ci/builds/36#cfbebc7e-4323-4a99-a… [3] https://buildkite.com/docs/agent/v3 [4] https://buildkite.com/docs/pipelines/defining-steps#example-pipeline [5] https://github.com/rust-vmm/community/issues/42 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

Adding ARM support to kvm-ioctls
by Florescu, Andreea 26 Mar '19

26 Mar '19

Hey everyone, I am working on adding an initial implementation for kvm-ioctls, PR here [1]. In the meantime, Diana (in cc) is working for adding ARM support for Firecracker and she would be interested in adding the required ARM ioctls directly to the kvm-ioctls crate. Does anybody have major concerns regarding the first version of the kvm-ioctls crate? I would like to get it merged to unblock the work on ARM. Regards, Andreea [1] https://github.com/rust-vmm/kvm-ioctls/pull/3 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.

4 4

Proposal for contribution and crate approval process
by Jonathan Bryce 19 Mar '19

19 Mar '19

Hi everyone, On the rust-vmm community meeting this morning there was a discussion about the approval process for new crates. From the discussion a basic proposal emerged: - Create a group of rust-vmm project-wide maintainers - Group size would start out with around 5 individuals - Maintainers should come from a variety of backgrounds and affiliations - Inclusion of a new crate would require approval from at least 3 maintainers - Maintainers should look for approval and feedback from multiple “consumer" communities (e.g. qemu, crosvm, kata, firecracker) - As the number of crates scale, maintenance at the crate level would be distributed beyond the project-wide group to avoid overloading the project-wide maintainers or creating bottlenecks within individual crates I offered to write this up and post on the list to make sure everyone had a chance to see and comment on it, so please send your thoughts/feedback. If this is agreeable as a process, we’ll need to bootstrap the initial set of maintainers. I have thoughts on that as well, but would love to hear others’ opinions too. Thanks, Jonathan

9 12

Re: [Rust-VMM] Crate Addition Request: CPU model
by Jenny Mankin 19 Mar '19

19 Mar '19

We have a need for a similar VCPU crate, and have been working on some POC code for it. I have put up a proposal here: https://github.com/rust-vmm/community/issues/40. Based on what I'm reading from your proposal, it sounds like there might some complementary functionality. I'd be interested in your feedback on our crate proposal, as we should stay in touch/work together on feedback in the designs for each to ensure both needs are complementary met. On 19-03-11 14:39:42, Paolo Bonzini wrote: > On 11/03/19 02:31, Yi Sun wrote: > > ## Crate Name > > > > 'cpu-model' > > > > ## Short Description > > > > A crate to provide a generic framework which has standard interfaces > > and flexible mechanism to support customized CPU models. > > > > ## Why is this crate relevant to the rust-vmm project? > > > > Customized CPU model is necessary because of below reasons. > > 1. Avoid CPU hardware vulnerabilities. > > 2. Keep stable guest ABI. > > 3. Hard requirement for live migration. > > What is in the definition of a CPU model? I would expect stuff like: > > 1) converting CPUID leaf (eax+ecx)/register/bit from and to a string > > 2) converting MSR bit from and to a string > > 3) dependencies between CPUID leaves and from CPUID leaves to MSRs > > 4) XSAVE area offsets > > 5) dependencies between CPUID leaves and XSAVE areas > > Anything else? > Above things are my first plan to handle model related resources. The crate should be generic and hypervisor agnostic. It defines a standard template and interfaces to make user easily configure features/register/msr/etc. Furthermore, provide a parameter to make user be able to add/remove feature when launching rust-vmm to dynamically adjust features. Because above things are part of CPU resources management, as the second step, I want to extend it to handle CPU states, address space, interrupts, etc. The goal is also generic and hypervisor agnostic. At last, I'd like to implement cpu hotplug, live migration to extend it be a comprehensive cpu management crate. It is a big blueprint. I will try to start from the easy part first. :) > Paolo _______________________________________________ Rust-vmm mailing list Rust-vmm(a)lists.opendev.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opendev.org_cgi-2…

3 2

subscribe
by Jeffrey Rombough 18 Mar '19

18 Mar '19

1 0

Crate Addition Request: CPU model
by Yi Sun 12 Mar '19

12 Mar '19

## Crate Name 'cpu-model' ## Short Description A crate to provide a generic framework which has standard interfaces and flexible mechanism to support customized CPU models. ## Why is this crate relevant to the rust-vmm project? Customized CPU model is necessary because of below reasons. 1. Avoid CPU hardware vulnerabilities. 2. Keep stable guest ABI. 3. Hard requirement for live migration.

3 3

CI presentation
by Bradford, Robert 12 Mar '19

12 Mar '19

Hi folks, Unfortunately we ran out of time in the meeting yesterday to cover the presentation of the NEMU CI that we had planned. I've attached it here and so perhaps we can discuss it via email instead. Of particular note is the last slide where we're (Intel) are proposing to setup a Jenkins CI PoC and do the work on the current crates to get them running through there. Let me know what you think of this idea. Rob

4 5