Re: [Xen-devel] Rudolph: merging Vixen and Comet

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jan 16, 2018 at 12:46:10PM +0000, Wei Liu wrote:
> On Fri, Jan 12, 2018 at 01:24:09PM +0000, Wei Liu wrote:
> > Hi all,
> > 
> > Two solutions are proposed to mitigate Meltdown. One is called Vixen and the
> > other is called Comet. The long term goal is to merge the two 
> > implementations
> > to one.
> > 
> > Here I list the differences between the two implementations.
> > 
> >                       Vixen                          Comet
> > Boot mode             HVM                            PVH + HVM
> > Kconfig options       XEN_GUEST                      XEN_GUEST + PVH_GUEST 
> > + SHIM_EXCLUSIVE
> > Xen build system      No change                      New build target for 
> > shim 
> > Guest console         Output only                    Bi-directional
> > Guest domid           1 or set via shim option       1 or retrieved via 
> > cpuid
> > Guest type            Hardware domain                Normal domain
> > Time source           Emulated                       Xen PV clock
> > Shutdown              PV + HW                        PV
> > SI mapping            Reserved page                  Fixed map, PFN chosen 
> > at runtime
> > VCPU id               Handled by L1                  Provide by L0 if 
> > available
> > VCPU runstate         Forwarded to L0                Handled by L1
> > Xen version           L0 version                     L1 version
> > CPUID faulting        None                           Changes for Intel and 
> > AMD
> > Grant table           What is forwarded is more or less the same but 
> > differs in implementation
> > Event channel setup   3 mechanisms                   1 mechanism
> > Event channel         ECS_PROXY state                Use ECS_RESERVED
> >                       Differences in what gets forwarded
> > Migration             No                             Yes
> > CPU hotplug           No                             Yes
> > Memory hotplug        No                             Yes
> > 
> > These are the things I can think of when comparing the two series side
> > by side.  Feel free to provide addition and / or correction.  The list
> > serves as a guidance on what areas need attention.
> 
> We've come to agree on the following goals among stakeholders:
> 
> 1. We will use Comet as base to develop Rudolph.
> 2. We will start to commit patches into staging and develop there.
> 3. We will maintain Vixen and Comet until Rudolph is ready. We will
>    be cherry-picking bug fixes to Vixen and Comet as we develop Rudolph.
> 
> In order to make goal #3 easier, I suggest we commit Comet almost as-is
> to minimise the difference between staging and backported Comet
> branches.
> 
> I will post a version of Comet suitable for committing to staging as
> soon as possible.  We will start porting over functionalities from Vixen
> once Comet is committed.

I've pushed comet-for-unstable to my xenbits/xen.git. That branch is a
forward port of 4.10.0-shim-comet branch to staging.

https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/heads/comet-for-unstable

There will be follow-up patches to fix some bugs, which have not been
pushed to that branch yet:

1. Michael Young's -xen-attach patch
2. Roger's patch to move mapping vcpu_info earlier

(Due to things go in parallel, they are probably not yet on list)

Jan and Andrew, please check the branch and explicitly ack the action of
committing that branch.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel