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

[Roger Pau Monné <roger.pau@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.

Iff maintainers agree that a version of Comet will be committed to
staging now I think it should be 4.10.0-shim-comet rebased into
staging, so that further patches (including bugfixes) can be easily
backported to the 4.10.0-shim-comet branch.

Or else the whole point of committing something to staging is not so
important IMHO.

Roger.

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