[Rust-VMM] Crate Addition Request: CPU model
yi.y.sun at linux.intel.com
Tue Mar 19 05:57:54 UTC 2019
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
> 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
More information about the Rust-vmm