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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jan 16, 2018 at 01:03:06PM +0000, Roger Pau Monné wrote:
> 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.
> 

There isn't any substantial difference between comet-4.10 and the
version I'm going to post other than I clean up the commit message a bit
and collect tags if applicable. I can also pick comet-4.10 if people
prefer that.  I don't really care.

Wei.

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