[Rust-VMM] Crate Addition Request: CPU model

[Yi 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=