From robert.bradford at intel.com Thu Mar 7 10:56:12 2019 From: robert.bradford at intel.com (Bradford, Robert) Date: Thu, 7 Mar 2019 10:56:12 +0000 Subject: [Rust-VMM] CI presentation Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: NEMU_CI.pdf Type: application/pdf Size: 98092 bytes Desc: NEMU_CI.pdf URL: From fandree at amazon.com Thu Mar 7 16:05:04 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Thu, 7 Mar 2019 16:05:04 +0000 Subject: [Rust-VMM] CI presentation In-Reply-To: References: Message-ID: <1551974701318.42311@amazon.com> Hey Rob, Thanks for putting together this presentation. I have some comments in terms of supported platforms: - Firecracker also has AMD in the roadmap so ideally we would like the crates to be tested on AMD as well. - I am slightly against using nested virtualization for the CI. Maybe it is appropriate for some crates, but it is not one a catch-it-all solutions. I might be biased here, but we should probably test on bare metal instances so we can be as close as possible to a production setup. Also, I have some concerns around performance testing on nested-virt. Amazon can offer some bare metal instances for the rust-vmm CI. I am not very familiar with Jenkins and I have some questions: 1. Does Jenkins take care of a clean environment for each run (either PRs or merges)? Do we have to implement our own methods to insure that? In the Firecracker CI we are always starting a new instance to run the tests. On that instance we do not have anything pre-configured. Every dependency lies in a container and that's how we make sure we are always testing all PRs in the same manner. 2. How easy is it to have smoke testing? I would put `cargo build --release` as a smoke test as we shouldn't want to run all tests in case the build doesn't work. Also, what are your thoughts around coverage? I didn't find any CI tool that can enforce coverage doesn't drop on PRs when the crate requires access to /dev/kvm. Coveralls[1] doesn't seem to have support for Rust. Codecov[2] might be a good candidate, but I failed to understand how to make it run on a bare-metal instance. To be fair, I also didn't spend a lot of time trying to understand it. Thanks, Andreea [1] https://coveralls.io/ [2] https://codecov.io/ ________________________________________ From: Bradford, Robert Sent: Thursday, March 7, 2019 12:56 PM To: rust-vmm at lists.opendev.org Subject: [Rust-VMM] CI presentation 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 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. From samuel.ortiz at intel.com Thu Mar 7 16:24:27 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Thu, 7 Mar 2019 17:24:27 +0100 Subject: [Rust-VMM] CI presentation In-Reply-To: <1551974701318.42311@amazon.com> References: <1551974701318.42311@amazon.com> Message-ID: <20190307162427.GK7594@caravaggio> Hi Andreea, On Thu, Mar 07, 2019 at 04:05:04PM +0000, Florescu, Andreea wrote: > Hey Rob, > > Thanks for putting together this presentation. > > I have some comments in terms of supported platforms: > - Firecracker also has AMD in the roadmap so ideally we would like the crates to be tested on AMD as well. > - I am slightly against using nested virtualization for the CI. Maybe it is appropriate for some crates, but it is not one a catch-it-all solutions. I might be biased here, but we should probably test on bare metal instances so we can be as close as possible to a production setup. Also, I have some concerns around performance testing on nested-virt. Amazon can offer some bare metal instances for the rust-vmm CI. > We've been using nested because it's the cheapest option. We use bare metal on Packet for aarch64. Having access to 100% bare metal is ideal and better, I agree. > I am not very familiar with Jenkins and I have some questions: > 1. Does Jenkins take care of a clean environment for each run (either PRs or merges)? Do we have to implement our own methods to insure that? In the Firecracker CI we are always starting a new instance to run the tests. On that instance we do not have anything pre-configured. Every dependency lies in a container and that's how we make sure we are always testing all PRs in the same manner. > 2. How easy is it to have smoke testing? I would put `cargo build --release` as a smoke test as we shouldn't want to run all tests in case the build doesn't work. > > Also, what are your thoughts around coverage? I didn't find any CI tool that can enforce coverage doesn't drop on PRs when the crate requires access to /dev/kvm. Coveralls[1] doesn't seem to have support for Rust. Codecov[2] might be a good candidate, but I failed to understand how to make it run on a bare-metal instance. To be fair, I also didn't spend a lot of time trying to understand it. > https://github.com/xd009642/tarpaulin is one tool that seems to be used for rust coverage. 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. From fandree at amazon.com Thu Mar 7 16:54:33 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Thu, 7 Mar 2019 16:54:33 +0000 Subject: [Rust-VMM] CI presentation In-Reply-To: <20190307162427.GK7594@caravaggio> References: <1551974701318.42311@amazon.com>,<20190307162427.GK7594@caravaggio> Message-ID: <1551977672483.14917@amazon.com> "Tarpaulin only supports x86_64 processors running Linux. " <- This makes me sad :( ________________________________________ From: Samuel Ortiz Sent: Thursday, March 7, 2019 6:24 PM To: Florescu, Andreea Cc: Bradford, Robert; rust-vmm at lists.opendev.org Subject: Re: [Rust-VMM] CI presentation Hi Andreea, On Thu, Mar 07, 2019 at 04:05:04PM +0000, Florescu, Andreea wrote: > Hey Rob, > > Thanks for putting together this presentation. > > I have some comments in terms of supported platforms: > - Firecracker also has AMD in the roadmap so ideally we would like the crates to be tested on AMD as well. > - I am slightly against using nested virtualization for the CI. Maybe it is appropriate for some crates, but it is not one a catch-it-all solutions. I might be biased here, but we should probably test on bare metal instances so we can be as close as possible to a production setup. Also, I have some concerns around performance testing on nested-virt. Amazon can offer some bare metal instances for the rust-vmm CI. > We've been using nested because it's the cheapest option. We use bare metal on Packet for aarch64. Having access to 100% bare metal is ideal and better, I agree. > I am not very familiar with Jenkins and I have some questions: > 1. Does Jenkins take care of a clean environment for each run (either PRs or merges)? Do we have to implement our own methods to insure that? In the Firecracker CI we are always starting a new instance to run the tests. On that instance we do not have anything pre-configured. Every dependency lies in a container and that's how we make sure we are always testing all PRs in the same manner. > 2. How easy is it to have smoke testing? I would put `cargo build --release` as a smoke test as we shouldn't want to run all tests in case the build doesn't work. > > Also, what are your thoughts around coverage? I didn't find any CI tool that can enforce coverage doesn't drop on PRs when the crate requires access to /dev/kvm. Coveralls[1] doesn't seem to have support for Rust. Codecov[2] might be a good candidate, but I failed to understand how to make it run on a bare-metal instance. To be fair, I also didn't spend a lot of time trying to understand it. > https://github.com/xd009642/tarpaulin is one tool that seems to be used for rust coverage. 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. 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. From msw at linux.com Fri Mar 8 20:04:54 2019 From: msw at linux.com (Matt Wilson) Date: Fri, 8 Mar 2019 12:04:54 -0800 Subject: [Rust-VMM] Proposal for contribution and crate approval process In-Reply-To: <95B66680-2B2E-4A51-A86F-4F9904838F14@openstack.org> References: <95B66680-2B2E-4A51-A86F-4F9904838F14@openstack.org> Message-ID: <20190308200454.GB12994@udb72c6a76a7559.ant.amazon.com> On Wed, Feb 20, 2019 at 02:25:56PM -0600, Jonathan Bryce wrote: > 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: Hi Jonathan, Thanks for writing this up, and for the infrastructure services from OpenDev. I have some thoughts about this that I'd like to share after a few disclosures: 1) I am an Amazon employee, and Amazon is contributing to rust-vmm through the efforts of other employees. I have an interest in how the rust-vmm community grows in that context. 2) I have not contributed code to rust-vmm, and I probably won't be able to participate in things like community calls due to my schedule. 3) My thoughts about how to foster open source communities that I'm sharing today are my own, and do not represent the views of my employer. Therefore I'm wearing my individual hat and sending this from my msw at linux.com email address. > - 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) I think it is much too early to establish this level of process about governance, number of maintainers, approval process, etc. Before establishing rules like this, I encourage communities to have a transparent discussion about exactly what problems they (as a community) are trying to solve. Due to my understanding of the intended nature of rust-vmm crates, as building blocks that can be used in other VMMs, this community may embrace a more decentralized approach with smaller numbers of contributors, and healthy forking of projects if the needs of a "downstream" are not met in the "upstream." There is no "one right way" to do open source. From past experience, we know of many successful patterns, and many anti-patterns. I have similar opinions about agile software development, and I encourage teams to discuss what works the best for them, rather than prescribing "you shall do agile development this way." I have found the most accessible way to have these discussions is via plain text email. Phone meetings and video conferences can be useful, but there are challenges in scheduling due to timezones and competing priorities. Additionally, they can exclude contributors that are unable to participate in speech based conversations. I encourage this emerging community to find what works well for the individuals who are showing up to collaborate, but be aware of who you may be unconsciously excluding. > - 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'm not sure what the overheads are here, having never done GitHub organization management. Again, my suggestion is to get experience with running the project before optimizing for a problem that might not exist. > 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. The idea that bootstrapping maintainers to reach a critical mass does not sit well with me. I would like to encourage a much more organic approach where natural leaders emerge based on their contributions establishing the direction and shared technology of a project. Finally, while things like logos are helpful promoting your project, it's probably not the first order of business. Nor is it the first order of business to obtain additional services from foundations. When I was a board member of Software Freedom Conservancy (of which QEMU is a member), and part of the Evaluation Committee considering applications to join, we established the following as part of the key criteria [1]: * The project should have an existing, vibrant, diverse community that develops and documents the software. For example, projects that have been under development for less than a year or only a "proof of concept" implementation are generally not eligible. Figure out who you are as a community, what problems you're trying to solve, and how you want to interact with one another as individuals. Creating a safe environment where people can collaborate and earn trust of one another should be a high priority. Make very intentional decisions here first. Experiment, double down on what works, and re-evaluate when things don't. Discuss it intently on a mailing list (... or don't, I do not have all of the answers here.) --msw [1] https://sfconservancy.org/projects/apply/ From zachr at google.com Fri Mar 8 21:15:01 2019 From: zachr at google.com (Zach Reizner) Date: Fri, 8 Mar 2019 13:15:01 -0800 Subject: [Rust-VMM] Proposal for contribution and crate approval process In-Reply-To: <20190308200454.GB12994@udb72c6a76a7559.ant.amazon.com> References: <95B66680-2B2E-4A51-A86F-4F9904838F14@openstack.org> <20190308200454.GB12994@udb72c6a76a7559.ant.amazon.com> Message-ID: On Fri, Mar 8, 2019 at 12:05 PM Matt Wilson wrote: > > On Wed, Feb 20, 2019 at 02:25:56PM -0600, Jonathan Bryce wrote: > > 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: > > Hi Jonathan, > > Thanks for writing this up, and for the infrastructure services from > OpenDev. I have some thoughts about this that I'd like to share after > a few disclosures: > > 1) I am an Amazon employee, and Amazon is contributing to rust-vmm > through the efforts of other employees. I have an interest in how > the rust-vmm community grows in that context. > 2) I have not contributed code to rust-vmm, and I probably won't be > able to participate in things like community calls due to my > schedule. > 3) My thoughts about how to foster open source communities that > I'm sharing today are my own, and do not represent the views of my > employer. Therefore I'm wearing my individual hat and sending this > from my msw at linux.com email address. > > > - 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) > > I think it is much too early to establish this level of process about > governance, number of maintainers, approval process, etc. Before > establishing rules like this, I encourage communities to have a > transparent discussion about exactly what problems they (as a > community) are trying to solve. Due to my understanding of the > intended nature of rust-vmm crates, as building blocks that can be > used in other VMMs, this community may embrace a more decentralized > approach with smaller numbers of contributors, and healthy forking of > projects if the needs of a "downstream" are not met in the "upstream." I agree with your statement about it being too early to establish such a high-level of governance. What you said about forking and decentralized approaches certainly matches my observations so far. >From my perspective, a decentralized fork (firecracker from crosvm) is part of how this organization got started. I don't see any signs of that stopping, as crosvm is starting to incorporate and modify vhost-user pieces posted here in order to adapt it to our code base. > > There is no "one right way" to do open source. From past experience, > we know of many successful patterns, and many anti-patterns. I have > similar opinions about agile software development, and I encourage > teams to discuss what works the best for them, rather than prescribing > "you shall do agile development this way." > > I have found the most accessible way to have these discussions is via > plain text email. Phone meetings and video conferences can be useful, > but there are challenges in scheduling due to timezones and competing > priorities. Additionally, they can exclude contributors that are > unable to participate in speech based conversations. I encourage this > emerging community to find what works well for the individuals who are > showing up to collaborate, but be aware of who you may be > unconsciously excluding. I also agree with that. The phone calls are somewhat earlier than my ordinary sleep schedule, which means I've only got to 2 of the last 3. The only other crosvm representative has only been to the first phone call. > > > - 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'm not sure what the overheads are here, having never done GitHub > organization management. Again, my suggestion is to get experience > with running the project before optimizing for a problem that might > not exist. > > > 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. > > The idea that bootstrapping maintainers to reach a critical mass does > not sit well with me. I would like to encourage a much more organic > approach where natural leaders emerge based on their contributions > establishing the direction and shared technology of a project. > > Finally, while things like logos are helpful promoting your project, > it's probably not the first order of business. Nor is it the first > order of business to obtain additional services from foundations. When > I was a board member of Software Freedom Conservancy (of which QEMU is > a member), and part of the Evaluation Committee considering > applications to join, we established the following as part of the key > criteria [1]: > > * The project should have an existing, vibrant, diverse community that > develops and documents the software. For example, projects that > have been under development for less than a year or only a "proof > of concept" implementation are generally not eligible. > > Figure out who you are as a community, what problems you're trying to > solve, and how you want to interact with one another as > individuals. Creating a safe environment where people can collaborate > and earn trust of one another should be a high priority. I think this is a perfect take-away. A lot of us are just meeting each other for the first time and it will take time for us to build up trust with each other. That should be our first goal as a shared organization. > > Make very intentional decisions here first. Experiment, double down on > what works, and re-evaluate when things don't. Discuss it intently on > a mailing list (... or don't, I do not have all of the answers here.) > > --msw > > [1] https://sfconservancy.org/projects/apply/ > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From yi.y.sun at linux.intel.com Mon Mar 11 01:31:05 2019 From: yi.y.sun at linux.intel.com (Yi Sun) Date: Mon, 11 Mar 2019 09:31:05 +0800 Subject: [Rust-VMM] Crate Addition Request: CPU model Message-ID: <20190311013105.GC5182@yi.y.sun> ## 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. From pbonzini at redhat.com Mon Mar 11 13:39:42 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Mon, 11 Mar 2019 14:39:42 +0100 Subject: [Rust-VMM] Crate Addition Request: CPU model In-Reply-To: <20190311013105.GC5182@yi.y.sun> References: <20190311013105.GC5182@yi.y.sun> Message-ID: 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? Paolo From robert.bradford at intel.com Mon Mar 11 14:02:54 2019 From: robert.bradford at intel.com (Bradford, Robert) Date: Mon, 11 Mar 2019 14:02:54 +0000 Subject: [Rust-VMM] CI presentation In-Reply-To: <1551974701318.42311@amazon.com> References: <1551974701318.42311@amazon.com> Message-ID: On Thu, 2019-03-07 at 16:05 +0000, Florescu, Andreea wrote: > Hey Rob, > > Thanks for putting together this presentation. > > I have some comments in terms of supported platforms: > - Firecracker also has AMD in the roadmap so ideally we would like > the crates to be tested on AMD as well. Sure, the system is flexible enough to have a mixture of fixed agents or agents that created on demand as the VMs are created. > - I am slightly against using nested virtualization for the CI. Maybe > it is appropriate for some crates, but it is not one a catch-it-all > solutions. I might be biased here, but we should probably test on > bare metal instances so we can be as close as possible to a > production setup. Also, I have some concerns around performance > testing on nested-virt. Amazon can offer some bare metal instances > for the rust-vmm CI. > That sounds great. One of the reasons for using the nested virtualisation, which also partly answers your question below, is that we wanted to not have any artifacts from the build remaining. As such we created an entirely new VM every time to build from scratch. Further testing on nested was also an interesting area to ensure testing as the majority of development of the project happened with NEMU as the L1 hypervisor. By using nesting we got coverage of L2 testing. > I am not very familiar with Jenkins and I have some questions: > 1. Does Jenkins take care of a clean environment for each run (either > PRs or merges)? Do we have to implement our own methods to insure > that? In the Firecracker CI we are always starting a new instance to > run the tests. On that instance we do not have anything pre- > configured. Every dependency lies in a container and that's how we > make sure we are always testing all PRs in the same manner. > 2. How easy is it to have smoke testing? I would put `cargo build -- > release` as a smoke test as we shouldn't want to run all tests in > case the build doesn't work. 1.) If your build scripts don't make system wide changes then you don't need to take any particular steps to ensure that the builds are clean (it's always new checkout and build directory.) That can be mitigated by us by either creating a new instance every time, running all the tests inside a filesystem namespace, or just by taking care to avoid contamination in the build system 2.) It's possible to fail early and cause the whole pipeline to abort if the most simplest step fails. > > Also, what are your thoughts around coverage? I didn't find any CI > tool that can enforce coverage doesn't drop on PRs when the crate > requires access to /dev/kvm. Coveralls[1] doesn't seem to have > support for Rust. Codecov[2] might be a good candidate, but I failed > to understand how to make it run on a bare-metal instance. To be > fair, I also didn't spend a lot of time trying to understand it. > I've not looked into coverage testing for Rust sadly. > Thanks, > Andreea > > [1] https://coveralls.io/ > [2] https://codecov.io/ > ________________________________________ > From: Bradford, Robert > Sent: Thursday, March 7, 2019 12:56 PM > To: rust-vmm at lists.opendev.org > Subject: [Rust-VMM] CI presentation > > 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 > > > > 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. > From cdupontd at redhat.com Mon Mar 11 17:02:11 2019 From: cdupontd at redhat.com (Christophe de Dinechin) Date: Mon, 11 Mar 2019 18:02:11 +0100 Subject: [Rust-VMM] CI presentation In-Reply-To: References: <1551974701318.42311@amazon.com> Message-ID: > On 11 Mar 2019, at 15:02, Bradford, Robert wrote: > > On Thu, 2019-03-07 at 16:05 +0000, Florescu, Andreea wrote: >> Hey Rob, >> >> Thanks for putting together this presentation. >> >> I have some comments in terms of supported platforms: >> - Firecracker also has AMD in the roadmap so ideally we would like >> the crates to be tested on AMD as well. > > Sure, the system is flexible enough to have a mixture of fixed agents > or agents that created on demand as the VMs are created. > >> - I am slightly against using nested virtualization for the CI. Maybe >> it is appropriate for some crates, but it is not one a catch-it-all >> solutions. I might be biased here, but we should probably test on >> bare metal instances so we can be as close as possible to a >> production setup. Also, I have some concerns around performance >> testing on nested-virt. Amazon can offer some bare metal instances >> for the rust-vmm CI. >> > > That sounds great. One of the reasons for using the nested > virtualisation, which also partly answers your question below, is that > we wanted to not have any artifacts from the build remaining. As such > we created an entirely new VM every time to build from scratch. Further > testing on nested was also an interesting area to ensure testing as the > majority of development of the project happened with NEMU as the L1 > hypervisor. By using nesting we got coverage of L2 testing. > > > >> I am not very familiar with Jenkins and I have some questions: >> 1. Does Jenkins take care of a clean environment for each run (either >> PRs or merges)? Do we have to implement our own methods to insure >> that? In the Firecracker CI we are always starting a new instance to >> run the tests. On that instance we do not have anything pre- >> configured. Every dependency lies in a container and that's how we >> make sure we are always testing all PRs in the same manner. >> 2. How easy is it to have smoke testing? I would put `cargo build -- >> release` as a smoke test as we shouldn't want to run all tests in >> case the build doesn't work. > > 1.) If your build scripts don't make system wide changes then you don't > need to take any particular steps to ensure that the builds are clean > (it's always new checkout and build directory.) That can be mitigated > by us by either creating a new instance every time, running all the > tests inside a filesystem namespace, or just by taking care to avoid > contamination in the build system You can also use the “Delete workspace before build starts” option under the project’s configuration “Build environment” settings. > > 2.) It's possible to fail early and cause the whole pipeline to abort > if the most simplest step fails. Yes. This is typically the case for normal build rules. You can also do more complicated chained setups if you want to reuse build artefacts from one project into another. But I don’t think it is necessary at that stage. > >> >> Also, what are your thoughts around coverage? I didn't find any CI >> tool that can enforce coverage doesn't drop on PRs when the crate >> requires access to /dev/kvm. Coveralls[1] doesn't seem to have >> support for Rust. Codecov[2] might be a good candidate, but I failed >> to understand how to make it run on a bare-metal instance. To be >> fair, I also didn't spend a lot of time trying to understand it. >> > > I've not looked into coverage testing for Rust sadly. > >> Thanks, >> Andreea >> >> [1] https://coveralls.io/ >> [2] https://codecov.io/ >> ________________________________________ >> From: Bradford, Robert >> Sent: Thursday, March 7, 2019 12:56 PM >> To: rust-vmm at lists.opendev.org >> Subject: [Rust-VMM] CI presentation >> >> 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 >> >> >> >> 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. >> > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From yi.y.sun at linux.intel.com Tue Mar 12 08:33:46 2019 From: yi.y.sun at linux.intel.com (Yi Sun) Date: Tue, 12 Mar 2019 16:33:46 +0800 Subject: [Rust-VMM] Crate Addition Request: CPU model In-Reply-To: References: <20190311013105.GC5182@yi.y.sun> Message-ID: <20190312083346.GD5182@yi.y.sun> 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 From jonathan at openstack.org Fri Mar 15 22:23:08 2019 From: jonathan at openstack.org (Jonathan Bryce) Date: Fri, 15 Mar 2019 17:23:08 -0500 Subject: [Rust-VMM] Proposal for contribution and crate approval process In-Reply-To: References: <95B66680-2B2E-4A51-A86F-4F9904838F14@openstack.org> <20190308200454.GB12994@udb72c6a76a7559.ant.amazon.com> Message-ID: <9A819EBD-523E-4716-8F97-CF3970BEA1B1@openstack.org> Thanks for taking the time to respond! I appreciate your sharing your thoughts and experiences. > On Mar 8, 2019, at 3:15 PM, Zach Reizner wrote: > > On Fri, Mar 8, 2019 at 12:05 PM Matt Wilson wrote: >> >> On Wed, Feb 20, 2019 at 02:25:56PM -0600, Jonathan Bryce wrote: >>> 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: >> >> Hi Jonathan, >> >> Thanks for writing this up, and for the infrastructure services from >> OpenDev. I have some thoughts about this that I'd like to share after >> a few disclosures: >> >> 1) I am an Amazon employee, and Amazon is contributing to rust-vmm >> through the efforts of other employees. I have an interest in how >> the rust-vmm community grows in that context. >> 2) I have not contributed code to rust-vmm, and I probably won't be >> able to participate in things like community calls due to my >> schedule. >> 3) My thoughts about how to foster open source communities that >> I'm sharing today are my own, and do not represent the views of my >> employer. Therefore I'm wearing my individual hat and sending this >> from my msw at linux.com email address. >> >>> - 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) >> >> I think it is much too early to establish this level of process about >> governance, number of maintainers, approval process, etc. Before >> establishing rules like this, I encourage communities to have a >> transparent discussion about exactly what problems they (as a >> community) are trying to solve. Due to my understanding of the >> intended nature of rust-vmm crates, as building blocks that can be >> used in other VMMs, this community may embrace a more decentralized >> approach with smaller numbers of contributors, and healthy forking of >> projects if the needs of a "downstream" are not met in the "upstream." > I agree with your statement about it being too early to establish such > a high-level of governance. What you said about forking and > decentralized approaches certainly matches my observations so far. > From my perspective, a decentralized fork (firecracker from crosvm) is > part of how this organization got started. I don't see any signs of > that stopping, as crosvm is starting to incorporate and modify > vhost-user pieces posted here in order to adapt it to our code base. Thanks for the feedback on the proposal. I have zero attachment to these ideas and was primarily putting them on the mailing list so the widest possible audience would have a chance to review and comment. So feel free to beat up on them as much as possible. I agree that too much governance too early in a project is bad. I tend to think of governance in its simplest form as an agreed upon (and ideally documented) method for making group decisions. While I don’t think there’s a need for heavyweight governance processes here right now, here’s the quick background on how this proposal came about. This additional context probably would have been good for me to include the first time around, so thanks for pushing on that, Matt. Andreea had previously put forward a basic process for creating crates in the organization. As several initial crates were proposed, people asked how much and what kind of review should be required before a crate should be considered accepted and included as part of the overall project. This was the specific item where there wasn’t yet an agreed upon method for making the group decision. Someone added this topic to the agenda for the call a few weeks back, and the people who were on wanted some way to review a crate before it was added as a repo, get input from multiple different stakeholders (e.g. crosvm & firecracker devs), and have something documented so that there would be agreement when a crate should be added and new contributors could have the correct expectations set if they were going to propose a new component. After chatting about it, it seemed like people had generally arrived at the above proposal, and I volunteered to put it on the mailing list so those who weren’t on the call could weigh in. Earlier in this thread someone had proposed a more unified architecture across crates which seemed like something that most people agreed we didn’t want. That was abandoned by the poster. On the above component addition proposal, I think it would be good to hear either specific changes or maybe some alternate ideas from the people who are actively working through existing crate proposals if we’d like to make some changes. I do think it’s useful to have something documented to set expectation for potential contributors, even if it’s lightweight. >> There is no "one right way" to do open source. From past experience, >> we know of many successful patterns, and many anti-patterns. I have >> similar opinions about agile software development, and I encourage >> teams to discuss what works the best for them, rather than prescribing >> "you shall do agile development this way." >> >> I have found the most accessible way to have these discussions is via >> plain text email. Phone meetings and video conferences can be useful, >> but there are challenges in scheduling due to timezones and competing >> priorities. Additionally, they can exclude contributors that are >> unable to participate in speech based conversations. I encourage this >> emerging community to find what works well for the individuals who are >> showing up to collaborate, but be aware of who you may be >> unconsciously excluding. > I also agree with that. The phone calls are somewhat earlier than my > ordinary sleep schedule, which means I've only got to 2 of the last 3. > The only other crosvm representative has only been to the first phone > call. Thanks for bringing up this point too, Matt. I’ve worked in communities with extremely diverse and global participants, and I agree with you that I have seen email as the most inclusive and reliable way to discuss and hash out topics. At the same time, I think that high-bandwidth collaboration opportunities can be super valuable, especially in early days as people are getting to know each other and building trust when individuals may hesitate to ship their ideas off to a public mailing list. One technique that I have seen help is to bring the ideas from the real-time discussions to an asynchronous medium as proposals and then allow people ample time to digest and share their opinions. I think that some people are comfortable using GitHub as the asynchronous medium, even though I may personally have an attachment to traditional mailing lists. But then, I also like IRC…call me old fashioned—or just old. I think it’s good to have an intentional discussion about where to drive these conversations, though. >> - 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'm not sure what the overheads are here, having never done GitHub >> organization management. Again, my suggestion is to get experience >> with running the project before optimizing for a problem that might >> not exist. >> >>> 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. >> >> The idea that bootstrapping maintainers to reach a critical mass does >> not sit well with me. I would like to encourage a much more organic >> approach where natural leaders emerge based on their contributions >> establishing the direction and shared technology of a project. >> >> Finally, while things like logos are helpful promoting your project, >> it's probably not the first order of business. Nor is it the first >> order of business to obtain additional services from foundations. When >> I was a board member of Software Freedom Conservancy (of which QEMU is >> a member), and part of the Evaluation Committee considering >> applications to join, we established the following as part of the key >> criteria [1]: >> >> * The project should have an existing, vibrant, diverse community that >> develops and documents the software. For example, projects that >> have been under development for less than a year or only a "proof >> of concept" implementation are generally not eligible. But logos are fun! = ) In all seriousness, I think logos are a fairly lightweight item that helps give a team of people that are distributed across countries and companies a sense of shared identity. >> Figure out who you are as a community, what problems you're trying to >> solve, and how you want to interact with one another as >> individuals. Creating a safe environment where people can collaborate >> and earn trust of one another should be a high priority. > I think this is a perfect take-away. A lot of us are just meeting each > other for the first time and it will take time for us to build up > trust with each other. That should be our first goal as a shared > organization. >> >> Make very intentional decisions here first. Experiment, double down on >> what works, and re-evaluate when things don't. Discuss it intently on >> a mailing list (... or don't, I do not have all of the answers here.) >> >> --msw >> >> [1] https://sfconservancy.org/projects/apply/ Thanks again for taking the time to chime in, Joanthan From jrombough2009 at hotmail.com Sun Mar 17 20:09:19 2019 From: jrombough2009 at hotmail.com (Jeffrey Rombough) Date: Sun, 17 Mar 2019 20:09:19 +0000 Subject: [Rust-VMM] subscribe Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdupontd at redhat.com Tue Mar 12 10:54:06 2019 From: cdupontd at redhat.com (Christophe de Dinechin) Date: Tue, 12 Mar 2019 11:54:06 +0100 Subject: [Rust-VMM] Crate Addition Request: CPU model In-Reply-To: References: <20190311013105.GC5182@yi.y.sun> Message-ID: <098E7DED-926B-41C7-BEE4-84E2955ACF03@redhat.com> > On 11 Mar 2019, at 14:39, 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 Maybe flags to access CPUID bits by name? > > Anything else? > > Paolo > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From jenny.mankin at crowdstrike.com Mon Mar 18 16:56:10 2019 From: jenny.mankin at crowdstrike.com (Jenny Mankin) Date: Mon, 18 Mar 2019 16:56:10 +0000 Subject: [Rust-VMM] Crate Addition Request: CPU model Message-ID: <3a4aa690647c4fd09d62d230cd870d86@Casmbox03.crowdstrike.sys> 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 at lists.opendev.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opendev.org_cgi-2Dbin_mailman_listinfo_rust-2Dvmm&d=DwIGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=PoK8upqsrqMY9Q21QxWB0ENVVKaX285kXk_XNb3b0rA&m=LBKXWfWC6ZZuPEP2kTh90p-4Vemm8N2Kh3G0nJd9o3I&s=HPhFlHHIcRPyx0zZyr7prvsYD4wyfwFSw_RMwmaI-7M&e= -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4905 bytes Desc: not available URL: From pbonzini at redhat.com Mon Mar 18 17:20:59 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Mon, 18 Mar 2019 18:20:59 +0100 Subject: [Rust-VMM] Crate Addition Request: CPU model In-Reply-To: <3a4aa690647c4fd09d62d230cd870d86@Casmbox03.crowdstrike.sys> References: <3a4aa690647c4fd09d62d230cd870d86@Casmbox03.crowdstrike.sys> Message-ID: On 18/03/19 17:56, Jenny Mankin wrote: > > 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. Yeah, there is hardly any overlap between your proposal and the one below. Your crate is probably part of a bigger discussion on how to handle multiple hypervisors. I commented on the pull request. Paolo >> 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? From msw at linux.com Mon Mar 18 18:58:14 2019 From: msw at linux.com (Matt Wilson) Date: Mon, 18 Mar 2019 11:58:14 -0700 Subject: [Rust-VMM] Proposal for contribution and crate approval process In-Reply-To: <9A819EBD-523E-4716-8F97-CF3970BEA1B1@openstack.org> References: <95B66680-2B2E-4A51-A86F-4F9904838F14@openstack.org> <20190308200454.GB12994@udb72c6a76a7559.ant.amazon.com> <9A819EBD-523E-4716-8F97-CF3970BEA1B1@openstack.org> Message-ID: <20190318185755.GA10718@udb72c6a76a7559.ant.amazon.com> On Fri, Mar 15, 2019 at 05:23:08PM -0500, Jonathan Bryce wrote: > Thanks for taking the time to respond! I appreciate your sharing > your thoughts and experiences. My pleasure! Thank you for supporting this emerging community. :-) > > On Mar 8, 2019, at 3:15 PM, Zach Reizner wrote: [...] > > I agree with your statement about it being too early to establish such > > a high-level of governance. What you said about forking and > > decentralized approaches certainly matches my observations so far. > > From my perspective, a decentralized fork (firecracker from crosvm) is > > part of how this organization got started. I don't see any signs of > > that stopping, as crosvm is starting to incorporate and modify > > vhost-user pieces posted here in order to adapt it to our code base. > > Thanks for the feedback on the proposal. I have zero attachment to > these ideas and was primarily putting them on the mailing list so > the widest possible audience would have a chance to review and > comment. So feel free to beat up on them as much as possible. Yup! I didn't take your conveying the notes from the call to mean they were your ideas. > I agree that too much governance too early in a project is bad. I > tend to think of governance in its simplest form as an agreed upon > (and ideally documented) method for making group decisions. While I > don’t think there’s a need for heavyweight governance processes here > right now, here’s the quick background on how this proposal came > about. This additional context probably would have been good for me > to include the first time around, so thanks for pushing on that, > Matt. > > Andreea had previously put forward a basic process for creating > crates in the organization. As several initial crates were proposed, > people asked how much and what kind of review should be required > before a crate should be considered accepted and included as part of > the overall project. This was the specific item where there wasn’t > yet an agreed upon method for making the group decision. Got it. I think we need to provide some guidance on when process is important. Processes sometimes become a proxy for the thing that you're really after. Let's say it's quality: you may adopt a process that includes some steps between doing development and testing, and a process for turning bugs into test cases. If you're not careful, the process can become the thing everyone focuses their attention on, and the outcomes are lost. When considering this question, "what kind of review should be required before a create should be considered accepted [...]?" first I would want to understand what are the downsides to accepting any new crate that is aligned to the overall charter of the project? Is this a one way door? Does it take a lot of resources from the members of the project to accept a new crate? Why not allow new crates to be developed outside of the community, and "graduate" them in? > Someone added this topic to the agenda for the call a few weeks > back, and the people who were on wanted some way to review a crate > before it was added as a repo, get input from multiple different > stakeholders (e.g. crosvm & firecracker devs), and have something > documented so that there would be agreement when a crate should be > added and new contributors could have the correct expectations set > if they were going to propose a new component. Being a Rust novice, I don't know if the concern here is namespace management, or something else. > After chatting about it, it seemed like people had generally arrived > at the above proposal, and I volunteered to put it on the mailing > list so those who weren’t on the call could weigh in. And thank you for doing so! :-) > Earlier in this thread someone had proposed a more unified > architecture across crates which seemed like something that most > people agreed we didn’t want. That was abandoned by the poster. On > the above component addition proposal, I think it would be good to > hear either specific changes or maybe some alternate ideas from the > people who are actively working through existing crate proposals if > we’d like to make some changes. I do think it’s useful to have > something documented to set expectation for potential contributors, > even if it’s lightweight. I think it would be good to talk about some design tenets or principles. Rather than documenting the governance / process, first set down what problems you're trying to solve, and general thinking about how the group might want to solve them. It may be that a highly decentralized and a "please feel free to fork" mentality will be more aligned with the problems that are being tackled by the individuals here. > >> There is no "one right way" to do open source. From past experience, [...] > >> unable to participate in speech based conversations. I encourage this > >> emerging community to find what works well for the individuals who are > >> showing up to collaborate, but be aware of who you may be > >> unconsciously excluding. > > > > I also agree with that. The phone calls are somewhat earlier than my > > ordinary sleep schedule, which means I've only got to 2 of the last 3. > > The only other crosvm representative has only been to the first phone > > call. > > Thanks for bringing up this point too, Matt. I’ve worked in > communities with extremely diverse and global participants, and I > agree with you that I have seen email as the most inclusive and > reliable way to discuss and hash out topics. At the same time, I > think that high-bandwidth collaboration opportunities can be super > valuable, especially in early days as people are getting to know > each other and building trust when individuals may hesitate to ship > their ideas off to a public mailing list. One technique that I have > seen help is to bring the ideas from the real-time discussions to an > asynchronous medium as proposals and then allow people ample time to > digest and share their opinions. I agree with all of this as well. > I think that some people are comfortable using GitHub as the > asynchronous medium, even though I may personally have an attachment > to traditional mailing lists. But then, I also like IRC…call me old > fashioned—or just old. I think it’s good to have an intentional > discussion about where to drive these conversations, though. I, too, have an affinity to traditional mailing list and IRC over GitHub and Slack. :-) I support having an intentional discussion, and ultimately the folks who will be having those conversations more regularly than I will chime in will figure it out. [...] > But logos are fun! = ) In all seriousness, I think logos are a > fairly lightweight item that helps give a team of people that are > distributed across countries and companies a sense of shared > identity. It's true, logos are fun. I'm mainly making a fuss to highlight the importance of the other things. [...] > > Thanks again for taking the time to chime in, My pleasure, and thanks again for your support. --msw From yi.y.sun at linux.intel.com Tue Mar 19 05:57:54 2019 From: yi.y.sun at linux.intel.com (Yi Sun) Date: Tue, 19 Mar 2019 13:57:54 +0800 Subject: [Rust-VMM] Crate Addition Request: CPU model In-Reply-To: <3a4aa690647c4fd09d62d230cd870d86@Casmbox03.crowdstrike.sys> References: <3a4aa690647c4fd09d62d230cd870d86@Casmbox03.crowdstrike.sys> Message-ID: <20190319055754.GE5182@yi.y.sun> On 19-03-18 16:56:10, Jenny Mankin wrote: > > 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. > I just replied on issue #40. I am working on vcpu and cpu-model now to make them hypervisor agnostic. As you have similar idea, we may co-work together. For hypervisor agnostic, I have some thoughts to discuss with you. Your idea is to implement different vcpu for different hypervisor. My idea is to abstract a "hypervisor" trait and implement it for KVM/HyperV/etc. Vcpu calls the common interfaces. The abstraction layer is different. Your idea may result less changes to current Firecracker/CrosVM. But mine seems more natural. Could you please consider my proposal and provide feedback? Thanks! > 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 at lists.opendev.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opendev.org_cgi-2Dbin_mailman_listinfo_rust-2Dvmm&d=DwIGaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=PoK8upqsrqMY9Q21QxWB0ENVVKaX285kXk_XNb3b0rA&m=LBKXWfWC6ZZuPEP2kTh90p-4Vemm8N2Kh3G0nJd9o3I&s=HPhFlHHIcRPyx0zZyr7prvsYD4wyfwFSw_RMwmaI-7M&e= From thierry at openstack.org Tue Mar 19 10:35:26 2019 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 19 Mar 2019 11:35:26 +0100 Subject: [Rust-VMM] Proposal for contribution and crate approval process In-Reply-To: <20190318185755.GA10718@udb72c6a76a7559.ant.amazon.com> References: <95B66680-2B2E-4A51-A86F-4F9904838F14@openstack.org> <20190308200454.GB12994@udb72c6a76a7559.ant.amazon.com> <9A819EBD-523E-4716-8F97-CF3970BEA1B1@openstack.org> <20190318185755.GA10718@udb72c6a76a7559.ant.amazon.com> Message-ID: <95a8f978-8528-51f1-4015-4884b6a9a44e@openstack.org> Matt Wilson wrote: > [...] > I think it would be good to talk about some design tenets or > principles. Rather than documenting the governance / process, first > set down what problems you're trying to solve, and general thinking > about how the group might want to solve them. It may be that a highly > decentralized and a "please feel free to fork" mentality will be more > aligned with the problems that are being tackled by the individuals > here. I agree... In the excitement of forming an open collaboration like this, we often skip the step where we put words to describe the exact scope of the project and its community, what is "in" and what is "out". If the project is successful, this can lead to scope creep and a community tempted to tackle more and more use cases... until the project becomes too big, vague or complex. So I would focus on three angles for a start: 1- What is the scope of the project -- in particular, describe what it will *not* do and leave to other adjacent projects 2- What are the key design tenets to follow when writing Rust-VMM crates 3- What are the community principles that this open collaboration follows A few example documents: Matt pointed at the Redis manifesto, which insists on the (2) angle: https://github.com/antirez/redis/blob/unstable/MANIFESTO The "Guiding principles" for OpenStack, which insist on the (3) angle: https://governance.openstack.org/tc/reference/principles.html -- Thierry Carrez (ttx) From james at openstack.org Tue Mar 19 23:29:01 2019 From: james at openstack.org (James Cole) Date: Tue, 19 Mar 2019 16:29:01 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts Message-ID: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> 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 . 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Rust-VMM_LogoConcepts_R1.pdf Type: application/pdf Size: 400910 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From msw at linux.com Wed Mar 20 00:17:55 2019 From: msw at linux.com (Matt Wilson) Date: Tue, 19 Mar 2019 17:17:55 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> On Tue, Mar 19, 2019 at 04:29:01PM -0700, James Cole wrote: > 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 > . Hi James, Before going too far, I want to make sure that the community understands the nature of this contribution. Under what license are you, or the OpenStack Foundation, proposing this work to this (still forming) community? Which way does this community want to go: * establishing trademarks * simply control the ability to manipulate or use the logo in commerce via a license like CC BY-NA-ND 4.0 * encourage anyone to be able to take a base logo and enhance it for their own purposes via something like CC0? In my opinion the "rust-vmm" project name is delightfully minimalist and utilitarian. It says what it is on the tin. It likely can't be trademarked on its own (consult a lawyer if you want an opinion on this. I am not one). If someone wants to create a logo, I see no reason to say they shouldn't. But in the discussion about what is "in" and what is "out" [2], I think this community should consider how much time and effort it wants to put into marketing, and creating things that can be more cumbersome to deal with than software. Maybe this community wants to establish its identity by eschewing logos at this time? I am an outsider, and haven't participated in any discussions about this, other than posting on the mailing list. What do you all think? --msw [1] https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode [2] http://lists.opendev.org/pipermail/rust-vmm/2019-March/000161.html From allison at lohutok.net Wed Mar 20 12:57:23 2019 From: allison at lohutok.net (Allison Randal) Date: Wed, 20 Mar 2019 08:57:23 -0400 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> Message-ID: <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> On 3/20/19 12:17 AM, Matt Wilson wrote: > > Maybe this community wants to establish its identity by eschewing > logos at this time? I am an outsider, and haven't participated in any > discussions about this, other than posting on the mailing list. > > What do you all think? Hi Matt, You are right that logos are sometimes used in that highly formalized way, but they don't have to be. For example, the OpenStack foundation logo does have a trademark program associated with it, similar to the Rust logo. But most of the project logos within OpenStack are just a fun way for people who participate to show their involvement with a laptop sticker or t-shirt. The Rust-VMM community is just forming, so I wouldn't expect they will want or need anything more than a fun logo for laptop stickers at the moment. They certainly have the option of doing more formal things with the logo later, but they don't have to decide all that now. Allison From msw at linux.com Wed Mar 20 17:41:45 2019 From: msw at linux.com (Matt Wilson) Date: Wed, 20 Mar 2019 10:41:45 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> Message-ID: On Wed, Mar 20, 2019 at 5:59 AM Allison Randal wrote: > > On 3/20/19 12:17 AM, Matt Wilson wrote: > > > > Maybe this community wants to establish its identity by eschewing > > logos at this time? I am an outsider, and haven't participated in any > > discussions about this, other than posting on the mailing list. > > > > What do you all think? > > Hi Matt, > > You are right that logos are sometimes used in that highly formalized > way, but they don't have to be. For example, the OpenStack foundation > logo does have a trademark program associated with it, similar to the > Rust logo. But most of the project logos within OpenStack are just a fun > way for people who participate to show their involvement with a laptop > sticker or t-shirt. It might be helpful to have examples of other fun logos. > The Rust-VMM community is just forming, so I wouldn't expect they will > want or need anything more than a fun logo for laptop stickers at the > moment. They certainly have the option of doing more formal things with > the logo later, but they don't have to decide all that now. I think it's great to encourage the formation of a community's identity. Stickers are a nice way to get people engaged. At this stage I'd welcome anyone who wants to do art for fun as part of a contribution to this community. Personally I also wouldn't complain if lots of people make lots of stickers that include the name "rust-vmm." I wouldn't care if people wanted to keep the rights to their designs and be the exclusive seller of stickers. Others that are active in actually building the code might have a different opinion. I would just ask that all contributions to an open source project come with very clear usage rights. Code is not the only thing that needs a license. This community should not accept a code contribution without clear intent of the contributor in the way of explicit license or a patch to an existing licensed file. Please do the same for other contributions like art, if they are intended to become part of the community. --msw [1] https://www.openstack.org/brand/openstack-logo/ From dgilbert at redhat.com Wed Mar 20 17:45:41 2019 From: dgilbert at redhat.com (Dr. David Alan Gilbert) Date: Wed, 20 Mar 2019 17:45:41 +0000 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> Message-ID: <20190320174540.GE2791@work-vm> * Matt Wilson (msw at linux.com) wrote: > On Wed, Mar 20, 2019 at 5:59 AM Allison Randal wrote: > > > > On 3/20/19 12:17 AM, Matt Wilson wrote: > > > > > > Maybe this community wants to establish its identity by eschewing > > > logos at this time? I am an outsider, and haven't participated in any > > > discussions about this, other than posting on the mailing list. > > > > > > What do you all think? > > > > Hi Matt, > > > > You are right that logos are sometimes used in that highly formalized > > way, but they don't have to be. For example, the OpenStack foundation > > logo does have a trademark program associated with it, similar to the > > Rust logo. But most of the project logos within OpenStack are just a fun > > way for people who participate to show their involvement with a laptop > > sticker or t-shirt. > > It might be helpful to have examples of other fun logos. Perhaps the most fun is the logo of 'Ironic' (the openstack component for booting on bare metal): https://wiki.openstack.org/wiki/Ironic#Pixie_Boots.2C_the_Ironic_drummer_bear Dave > > The Rust-VMM community is just forming, so I wouldn't expect they will > > want or need anything more than a fun logo for laptop stickers at the > > moment. They certainly have the option of doing more formal things with > > the logo later, but they don't have to decide all that now. > > I think it's great to encourage the formation of a community's identity. > Stickers are a nice way to get people engaged. At this stage I'd welcome > anyone who wants to do art for fun as part of a contribution to this > community. Personally I also wouldn't complain if lots of people make > lots of stickers that include the name "rust-vmm." I wouldn't care if > people wanted to keep the rights to their designs and be the exclusive > seller of stickers. Others that are active in actually building the code > might have a different opinion. > > I would just ask that all contributions to an open source > project come with very clear usage rights. Code is not the only thing > that needs a license. This community should not accept a code contribution > without clear intent of the contributor in the way of explicit license > or a patch to an existing licensed file. > > Please do the same for other contributions like art, if they are > intended to become > part of the community. > > --msw > > [1] https://www.openstack.org/brand/openstack-logo/ > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm -- Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK From allison at lohutok.net Wed Mar 20 17:59:51 2019 From: allison at lohutok.net (Allison Randal) Date: Wed, 20 Mar 2019 13:59:51 -0400 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> Message-ID: <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> On 3/20/19 5:41 PM, Matt Wilson wrote: > > It might be helpful to have examples of other fun logos. The rustacean is a great example: http://rustacean.net/ Here's the list of the OpenStack project logos, together with information on licensing, and some fun background on how many of them were created: https://www.openstack.org/project-mascots/ (FYI, Rust-VMM isn't part of the OpenStack project, so doesn't require approval from the OpenStack technical committee, and some of the other info on that page isn't relevant. But, the artist(s) who did those logos had a lot of fun with it, and are happy to share their skills with other open source projects.) > I would just ask that all contributions to an open source > project come with very clear usage rights. Code is not the only thing > that needs a license. This community should not accept a code contribution > without clear intent of the contributor in the way of explicit license > or a patch to an existing licensed file. > > Please do the same for other contributions like art, if they are > intended to become > part of the community. Agreed on clear licensing. My personal preference is for Creative Commons licensing, picking the most open license that makes sense. Allison From msw at linux.com Wed Mar 20 20:10:08 2019 From: msw at linux.com (Matt Wilson) Date: Wed, 20 Mar 2019 13:10:08 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> Message-ID: On Wed, Mar 20, 2019 at 10:59 AM Allison Randal wrote: > > On 3/20/19 5:41 PM, Matt Wilson wrote: > > > > It might be helpful to have examples of other fun logos. > > The rustacean is a great example: > > http://rustacean.net/ > > Here's the list of the OpenStack project logos, together with > information on licensing, and some fun background on how many of them > were created: > > https://www.openstack.org/project-mascots/ > > (FYI, Rust-VMM isn't part of the OpenStack project, so doesn't require > approval from the OpenStack technical committee, and some of the other > info on that page isn't relevant. But, the artist(s) who did those logos > had a lot of fun with it, and are happy to share their skills with other > open source projects.) > [...] > > Agreed on clear licensing. My personal preference is for Creative > Commons licensing, picking the most open license that makes sense. Awesome. All of these have clear licenses (or a public domain dedication, in the case of Ferris the Rustacean) from their creators. :-) Thanks! --msw From jonathan at openstack.org Wed Mar 20 20:11:17 2019 From: jonathan at openstack.org (Jonathan Bryce) Date: Wed, 20 Mar 2019 15:11:17 -0500 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> Message-ID: > On Mar 20, 2019, at 12:41 PM, Matt Wilson wrote: > > On Wed, Mar 20, 2019 at 5:59 AM Allison Randal wrote: > >> The Rust-VMM community is just forming, so I wouldn't expect they will >> want or need anything more than a fun logo for laptop stickers at the >> moment. They certainly have the option of doing more formal things with >> the logo later, but they don't have to decide all that now. > > I think it's great to encourage the formation of a community's identity. > Stickers are a nice way to get people engaged. At this stage I'd welcome > anyone who wants to do art for fun as part of a contribution to this > community. Personally I also wouldn't complain if lots of people make > lots of stickers that include the name "rust-vmm." I wouldn't care if > people wanted to keep the rights to their designs and be the exclusive > seller of stickers. Others that are active in actually building the code > might have a different opinion. > > I would just ask that all contributions to an open source > project come with very clear usage rights. Code is not the only thing > that needs a license. This community should not accept a code contribution > without clear intent of the contributor in the way of explicit license > or a patch to an existing licensed file. > > Please do the same for other contributions like art, if they are > intended to become > part of the community. In terms of usage rights, we work as community members to contribute under the license a community likes to use just like any other contributor would. For art or other non-code it's usually some variation of Creative Commons: CC-BY-SA, CC-BY-NC, or CC-BY-NC-ND depending on the desires for re-use, commercial use, etc like you mentioned previously. Ironically, James and I had chatted about it before he sent his email and decided to leave the initial email focused on creative feedback vs licensing. > [1] https://www.openstack.org/brand/openstack-logo/ This is a set of agreements specifically for the OpenStack logo itself, which I consider a very different animal since it has a lot of direct commercial use in a multi-billion dollar ecosystem of products and services built around the various projects. Jonathan From msw at linux.com Thu Mar 21 03:17:55 2019 From: msw at linux.com (Matt Wilson) Date: Wed, 20 Mar 2019 20:17:55 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> Message-ID: On Wed, Mar 20, 2019 at 1:10 PM Matt Wilson wrote: > > On Wed, Mar 20, 2019 at 10:59 AM Allison Randal wrote: > > > > On 3/20/19 5:41 PM, Matt Wilson wrote: > > > > > > It might be helpful to have examples of other fun logos. > > > > The rustacean is a great example: > > > > http://rustacean.net/ > > [...] > > > > Agreed on clear licensing. My personal preference is for Creative > > Commons licensing, picking the most open license that makes sense. > > Awesome. All of these have clear licenses (or a public domain dedication, > in the case of Ferris the Rustacean) from their creators. :-) > > Thanks! After I learned about Ferris for the first time today (sorry, I'm not a Rust programmer... yet), the answer became clear in my mind. It's crustaceans all the way down. I have attached a .svg file with a quick mockup. I am using the CC0 dedication to place this modified Ferris the Rustacean in the public domain. The .svg file metadata includes a link to the CC0 dedication. --msw -------------- next part -------------- A non-text attachment was scrubbed... Name: rustacean-vmm-noshadow.svg Type: image/svg+xml Size: 28060 bytes Desc: not available URL: From msw at linux.com Thu Mar 21 04:50:44 2019 From: msw at linux.com (Matt Wilson) Date: Wed, 20 Mar 2019 21:50:44 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> Message-ID: On Wed, Mar 20, 2019 at 8:17 PM Matt Wilson wrote: > > After I learned about Ferris for the first time today (sorry, I'm not > a Rust programmer... yet), the answer became clear in my mind. > > It's crustaceans all the way down. Ahem, I meant **rustaceans** all the way down. > I have attached a .svg file with a quick mockup. I am using the CC0 > dedication to place this modified Ferris the Rustacean in the public > domain. The .svg file metadata includes a link to the CC0 dedication. Here's a .png export preview, for those that have trouble with .svg. --msw -------------- next part -------------- A non-text attachment was scrubbed... Name: rustacean-vmm-noshadow.png Type: image/png Size: 26229 bytes Desc: not available URL: From james at openstack.org Fri Mar 22 19:14:39 2019 From: james at openstack.org (James Cole) Date: Fri, 22 Mar 2019 12:14:39 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> Message-ID: <1418E973-963D-4349-8C39-0AEB7CC8E5B2@openstack.org> Hi everyone! Thanks for all the thoughts about logos, usage rights, and trademarks. A few thoughts regarding creative execution: If having a brand identity is something that is important to this community, it might be worthwhile to create something distinct from other visual identities in its space. It turns out a few of my concepts were a little too close to Ubuntu’s logo, so thats something I will remedy as I finesse some of these ideas. Although the crab concept is fun and a nice allusion to Rust, it may cause some confusion between the two projects if it is used as a logo, especially if someone is unfamiliar with either project. That’s not to say this project couldn’t have supporting graphical elements people create—especially if you’re not interested in defining brand guidelines—but having some type of brand identity is critical in differentiating a project from others in its space. In the case of Rust, they still use a primary logo (gear with an R in the center) but also have an unofficial mascot (the crab). A mascot is certainly something you could explore for Rust, but details tend to get lost at smaller sizes with things that are highly illustrative (think an avatar or social media icon). So that might be something to consider if anyone else is interested in creating logo ideas. Thanks for the feedback everybody! James Cole Graphic Designer OpenStack Foundation > On Mar 20, 2019, at 9:50 PM, Matt Wilson wrote: > > On Wed, Mar 20, 2019 at 8:17 PM Matt Wilson wrote: >> >> After I learned about Ferris for the first time today (sorry, I'm not >> a Rust programmer... yet), the answer became clear in my mind. >> >> It's crustaceans all the way down. > > Ahem, I meant **rustaceans** all the way down. > >> I have attached a .svg file with a quick mockup. I am using the CC0 >> dedication to place this modified Ferris the Rustacean in the public >> domain. The .svg file metadata includes a link to the CC0 dedication. > > Here's a .png export preview, for those that have trouble with .svg. > > --msw > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbonzini at redhat.com Mon Mar 25 13:24:15 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Mon, 25 Mar 2019 14:24:15 +0100 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <1418E973-963D-4349-8C39-0AEB7CC8E5B2@openstack.org> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> <1418E973-963D-4349-8C39-0AEB7CC8E5B2@openstack.org> Message-ID: <27c9076b-c36c-e329-85ec-30bbcc9e2000@redhat.com> On 22/03/19 20:14, James Cole wrote: > Hi everyone! Thanks for all the thoughts about logos, usage rights, and > trademarks. A few thoughts regarding creative execution:  > > If having a brand identity is something that is important to this > community, it might be worthwhile to create something distinct from > other visual identities in its space. It turns out a few of my concepts > were a little too close to Ubuntu’s logo, so thats something I will > remedy as I finesse some of these ideas. I liked the epicyclic gear idea. One note is that often I've seen epicyclic gears represented without the carrier on top. In fact it adds a bit of clutter to your concepts, at the same time three circles without the carrier are not very representative of an epicyclic gear. I assume you used circles inside, rather than gears, to avoid losing detail at lower resolutions? Would it make sense to vary the number of teeth as the resolution decreases? Paolo From fandree at amazon.com Mon Mar 25 14:38:12 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Mon, 25 Mar 2019 14:38:12 +0000 Subject: [Rust-VMM] Adding ARM support to kvm-ioctls Message-ID: <1553524691570.98830@amazon.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.ortiz at intel.com Mon Mar 25 14:45:54 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Mon, 25 Mar 2019 15:45:54 +0100 Subject: [Rust-VMM] Adding ARM support to kvm-ioctls In-Reply-To: <1553524691570.98830@amazon.com> References: <1553524691570.98830@amazon.com> Message-ID: <20190325144553.GG4527@caravaggio> Hi Andreea, On Mon, Mar 25, 2019 at 02:38:12PM +0000, Florescu, Andreea wrote: > 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. > It looks good to me. 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. From sebastien.boeuf at intel.com Mon Mar 25 14:57:10 2019 From: sebastien.boeuf at intel.com (Boeuf, Sebastien) Date: Mon, 25 Mar 2019 14:57:10 +0000 Subject: [Rust-VMM] Adding ARM support to kvm-ioctls In-Reply-To: <20190325144553.GG4527@caravaggio> References: <1553524691570.98830@amazon.com> <20190325144553.GG4527@caravaggio> Message-ID: <14e7b1f9d57e9a3d59e4ee68131b326356a3f8eb.camel@intel.com> On Mon, 2019-03-25 at 15:45 +0100, Samuel Ortiz wrote: > Hi Andreea, > > On Mon, Mar 25, 2019 at 02:38:12PM +0000, Florescu, Andreea wrote: > > 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. > > > > It looks good to me. Yes same here, but I would really want to make sure Zach approves it too, as we want to see crosvm reusing this crate. Sebastien > > 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. > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From fandree at amazon.com Mon Mar 25 16:06:23 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Mon, 25 Mar 2019 16:06:23 +0000 Subject: [Rust-VMM] Adding ARM support to kvm-ioctls In-Reply-To: <14e7b1f9d57e9a3d59e4ee68131b326356a3f8eb.camel@intel.com> References: <1553524691570.98830@amazon.com> <20190325144553.GG4527@caravaggio>, <14e7b1f9d57e9a3d59e4ee68131b326356a3f8eb.camel@intel.com> Message-ID: <1553529983475.71195@amazon.com> Hey, I sent an email to Zach as well a couple of day ago. Let me just copy paste parts of the email here in case somebody else from CrosVM wants to take a look at the PR. Hopefully this will help in the review process. The kvm-ioctls crate doesn't yet have all the functionality that you need in CrosVM, but I was planning on adding that in a following PR as this one is already quite large already. Some notable changes from the CrosVM kvm crate: - Kvm, Vcpu and Vm do not have a public constructor anymore. The Kvm class implements a create_vm method and the Vm class implements a create_vcpu method. I did this change so we can have the same separation of ioctls as found in the KVM implementation. - Each ioctl group lies in a different module, but that should not have any impact on how you use it because the ioctls are exported with pub use iocts::system::* and so on. - I use the io::Error instead of errno.rs. One of the reasons is the one we discussed about in the call (pretty printing errors). The other reason is that the vmm-sys-utils crate is not available for import just yet. - The crate does not depend on EventFd and uses a RawFd instead. I don't know if I missed something else. Let me know if you have any questions. Regards, Andreea ________________________________________ From: Boeuf, Sebastien Sent: Monday, March 25, 2019 3:57 PM To: Ortiz, Samuel; Florescu, Andreea Cc: Popa, Diana-Maria; rust-vmm at lists.opendev.org Subject: Re: [Rust-VMM] Adding ARM support to kvm-ioctls On Mon, 2019-03-25 at 15:45 +0100, Samuel Ortiz wrote: > Hi Andreea, > > On Mon, Mar 25, 2019 at 02:38:12PM +0000, Florescu, Andreea wrote: > > 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. > > > > It looks good to me. Yes same here, but I would really want to make sure Zach approves it too, as we want to see crosvm reusing this crate. Sebastien > > 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. > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm 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. From james at openstack.org Mon Mar 25 20:58:46 2019 From: james at openstack.org (James Cole) Date: Mon, 25 Mar 2019 13:58:46 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <27c9076b-c36c-e329-85ec-30bbcc9e2000@redhat.com> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> <1418E973-963D-4349-8C39-0AEB7CC8E5B2@openstack.org> <27c9076b-c36c-e329-85ec-30bbcc9e2000@redhat.com> Message-ID: Hey Paolo, thanks for the thoughts! My replies are below: > I liked the epicyclic gear idea. One note is that often I've seen > epicyclic gears represented without the carrier on top. In fact it adds > a bit of clutter to your concepts, at the same time three circles > without the carrier are not very representative of an epicyclic gear I like the idea of simplifying the gear concept, maybe only using two gears? Definitely something worth trying. > I assume you used circles inside, rather than gears, to avoid losing > detail at lower resolutions? Would it make sense to vary the number of > teeth as the resolution decreases? Yes exactly, the teeth become difficult to resolve at smaller sizes. I would hesitate recommending changing the design at different sizes—its usually more efficient and less confusing to have one thing that scales well. -James > On Mar 25, 2019, at 6:24 AM, Paolo Bonzini wrote: > > On 22/03/19 20:14, James Cole wrote: >> Hi everyone! Thanks for all the thoughts about logos, usage rights, and >> trademarks. A few thoughts regarding creative execution: >> >> If having a brand identity is something that is important to this >> community, it might be worthwhile to create something distinct from >> other visual identities in its space. It turns out a few of my concepts >> were a little too close to Ubuntu’s logo, so thats something I will >> remedy as I finesse some of these ideas. > > I liked the epicyclic gear idea. One note is that often I've seen > epicyclic gears represented without the carrier on top. In fact it adds > a bit of clutter to your concepts, at the same time three circles > without the carrier are not very representative of an epicyclic gear. > > I assume you used circles inside, rather than gears, to avoid losing > detail at lower resolutions? Would it make sense to vary the number of > teeth as the resolution decreases? > > Paolo > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From josh at joshtriplett.org Mon Mar 25 21:20:09 2019 From: josh at joshtriplett.org (Josh Triplett) Date: Mon, 25 Mar 2019 14:20:09 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> <1418E973-963D-4349-8C39-0AEB7CC8E5B2@openstack.org> <27c9076b-c36c-e329-85ec-30bbcc9e2000@redhat.com> Message-ID: <20190325212009.GA18087@localhost> On Mon, Mar 25, 2019 at 01:58:46PM -0700, James Cole wrote: > Hey Paolo, thanks for the thoughts! My replies are below: > > > I liked the epicyclic gear idea. One note is that often I've seen > > epicyclic gears represented without the carrier on top. In fact it adds > > a bit of clutter to your concepts, at the same time three circles > > without the carrier are not very representative of an epicyclic gear > > > I like the idea of simplifying the gear concept, maybe only using two gears? Definitely something worth trying. How about just a single gear-within-gear, the inner gear ~80% of the outer one, in the style of a spirograph? That might provide enough room to make the inner gear a full (simplifie) Rust logo. From dgreid at chromium.org Mon Mar 25 22:48:10 2019 From: dgreid at chromium.org (Dylan Reid) Date: Mon, 25 Mar 2019 15:48:10 -0700 Subject: [Rust-VMM] Adding ARM support to kvm-ioctls In-Reply-To: <1553529983475.71195@amazon.com> References: <1553524691570.98830@amazon.com> <20190325144553.GG4527@caravaggio> <14e7b1f9d57e9a3d59e4ee68131b326356a3f8eb.camel@intel.com> <1553529983475.71195@amazon.com> Message-ID: On Mon, Mar 25, 2019 at 9:06 AM Florescu, Andreea wrote: > > Hey, > > I sent an email to Zach as well a couple of day ago. > > Let me just copy paste parts of the email here in case somebody else from CrosVM wants to take a look at the PR. Hopefully this will help in the review process. > > The kvm-ioctls crate doesn't yet have all the functionality that you need in CrosVM, but I was planning on adding that in a following PR as this one is already quite large already. > Some notable changes from the CrosVM kvm crate: > > - Kvm, Vcpu and Vm do not have a public constructor anymore. The Kvm class implements a create_vm method and the Vm class implements a create_vcpu method. I did this change so we can have the same separation of ioctls as found in the KVM implementation. > - Each ioctl group lies in a different module, but that should not have any impact on how you use it because the ioctls are exported with pub use iocts::system::* and so on. > - I use the io::Error instead of errno.rs. One of the reasons is the one we discussed about in the call (pretty printing errors). The other reason is that the vmm-sys-utils crate is not available for import just yet. > - The crate does not depend on EventFd and uses a RawFd instead. Sorry that we've been less than responsive. It's a busy time of year for Chrome OS and allocating resources to these reviews is challenging. Generally, departures similar to those listed here are acceptable. As long as the new crates avoid external dependencies such as nix, rayon, etc. it won't make crosvm integration harder. Don't let a lack of review from crosvm block progress on the initial crates. It's more important to get something landed than for the first pass to be perfect. There will be a few iterations before we have both firecracker and crosvm rebased on top of the new crates. Hopefully we retain flexibility before we push these interfaces to a 1.0 release. Thanks, Dylan > > I don't know if I missed something else. > > Let me know if you have any questions. > > Regards, > Andreea > > ________________________________________ > From: Boeuf, Sebastien > Sent: Monday, March 25, 2019 3:57 PM > To: Ortiz, Samuel; Florescu, Andreea > Cc: Popa, Diana-Maria; rust-vmm at lists.opendev.org > Subject: Re: [Rust-VMM] Adding ARM support to kvm-ioctls > > On Mon, 2019-03-25 at 15:45 +0100, Samuel Ortiz wrote: > > Hi Andreea, > > > > On Mon, Mar 25, 2019 at 02:38:12PM +0000, Florescu, Andreea wrote: > > > 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. > > > > > > > It looks good to me. > > Yes same here, but I would really want to make sure Zach approves it > too, as we want to see crosvm reusing this crate. > > Sebastien > > > > 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. > > > > > > _______________________________________________ > > Rust-vmm mailing list > > Rust-vmm at lists.opendev.org > > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > > > > 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. > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From james at openstack.org Tue Mar 26 19:47:46 2019 From: james at openstack.org (James Cole) Date: Tue, 26 Mar 2019 12:47:46 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <20190325212009.GA18087@localhost> References: <20190320001755.GA5851@udb72c6a76a7559.ant.amazon.com> <5ed7570f-559e-6764-8c98-a5a15389fa2c@lohutok.net> <94f44d6e-b6ab-1273-e704-0e40427d3f39@lohutok.net> <1418E973-963D-4349-8C39-0AEB7CC8E5B2@openstack.org> <27c9076b-c36c-e329-85ec-30bbcc9e2000@redhat.com> <20190325212009.GA18087@localhost> Message-ID: > On Mar 25, 2019, at 2:20 PM, Josh Triplett wrote: > > How about just a single gear-within-gear, the inner gear ~80% of the > outer one, in the style of a spirograph? That might provide enough > room to make the inner gear a full (simplifie) Rust logo. That could work! A spirograph opens up another world of interesting ideas. -James -------------- next part -------------- An HTML attachment was scrubbed... URL: From fandree at amazon.com Wed Mar 27 13:10:05 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Wed, 27 Mar 2019 13:10:05 +0000 Subject: [Rust-VMM] rust-vmm CI & container Message-ID: <1553692204913.20834@amazon.com> 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-af6a-57c665c83a7c [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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.ortiz at intel.com Thu Mar 28 14:03:45 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Thu, 28 Mar 2019 15:03:45 +0100 Subject: [Rust-VMM] rust-vmm CI & container In-Reply-To: <1553692204913.20834@amazon.com> References: <1553692204913.20834@amazon.com> Message-ID: <20190328140345.GW4527@caravaggio> Hi Andreea, On Wed, Mar 27, 2019 at 01:10:05PM +0000, Florescu, Andreea wrote: > 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? > Yes. Access to /dev/kvm is the single requirement. It can be done on bare metal or on nested virt. Both setups may be needed for different test cases, and also because we may not get as many bare metal instances as needed to do parallel CI and e.g. performance testing at the same time. > 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. > One concern I may have about buildkite is that it's not open source unlike e.g. Jenkins. But to be fair, the same could be said about github and possibly several tools that we're going to use, so that's not a blocker for me. I like the simplicity and setup ease of buildkite, which are two really big cons for jenkins imo. Also, the pipeline description file looks simple and mostly complete for what we'd want to do with it. So all in all, this looks fine to me. > 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. > Makes sense to me, I commented on the issue. 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.