Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jan 10, 2018 at 08:32:24AM +0000, Roger Pau Monné wrote:
> On Tue, Jan 09, 2018 at 07:43:51PM +0000, Wei Liu wrote:
> > On Mon, Jan 08, 2018 at 05:45:32PM +0000, Ian Jackson wrote:
> > > AIUI we have a series for pv-in-pvh shim which is nearing completion
> > > in the sense that it will have been well-tested (especially the
> > > hypervisor parts) and has good functionality.  (Wei is handling the
> > > assembly of this series.)
> > > 
> > > The series, however, needs proper review and tidying up.
> > > Specifically, it needs the kind of tidying up that fixes code
> > > structure and style issues that will hinder future Xen development.
> > > I.e. the kind of technical debt which does not directly cause bugs now
> > > but will cause trouble (including bugs) in the future.
> > > 
> > > IMO that kind of tidying up is definitely essential for
> > > xen.git#master.  However, it is much less of an issue for Xen 4.10.
> > > Xen 4.10, as a stable branch, will get much more limited further
> > > development.  Failure to tidy things up there will make backporting
> > > other changes more awkward but the overall impact is both lower and
> > > time-bound.
> > > 
> > > Currently the Xen Project has no published resolution for PV guests
> > > that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> > > bring their own problems.)  We need to provide our users with more
> > > good options as quickly as possible.
> > > 
> > > I would like to suggest that a good way of doing this would be to ship
> > > the shim series as 4.10.1 within the next very few days.  It needs
> > > some minor bugfixing (build breakage etc.) but is basically ready for
> > > use.
> > > 
> > > Speaking as a sysadmin (even, a very conservative sysadmin many of
> > > whose systems are running Debian oldstable), I have already taken a
> > > decision to rapidly advance to new software, in one context, because
> > > of these vulnerabilities - and take and fix whatever impact that has.
> > > I think many of our users would like to make the same choice.
> > > 
> > > Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> > > our users with PV guests an immediately deployable update, even though
> > > of course the version bump to get to 4.10 may be disruptive.
> > > 
> > > Doing this would be a departure from our uusual non-security-bug
> > > process of committing changes to xen.git#staging, and then backporting
> > > only after the patches have been sitting in xen.git#master for some
> > > time.  It's also a departure from our usual security-bug process of
> > > developing and testing and committing patches for all supported
> > > versions in parallel.
> > > 
> > > But this is not a usual situation.  This time, we don't have the time
> > > to wait.
> > > 
> > > Opinions ?
> > > 
> > 
> > Anthony and others joined #xendevel to express their findings and
> > opinions.
> > 
> > Converging the PVH and HVM solution is doable and essential in the long
> > run, but merging the two series in two or three days (if we want to make
> > something ready this week) is not possible. It all comes down to which
> > series should we use for the temporary solution.
> > 
> > We discussed the test coverage of both series. It seems that the PV in
> > PVH series has had in depth testing done on 4.7 and 4.10, while PV in
> > HVM series has had testing done from Xen 3.4 onward with various old and
> > new guests. Anthony also pointed out that PV in PVH shim won't work for
> > some configurations -- there are far too many subtleties to fix without
> > time and testing resources (both of which upstream lacks). These are
> > rather strong arguments for the PV in HVM series, because being able to
> > run on older versions of Xen and older versions of guest kernels
> > provides our users with the maximum coverage.
> > 
> > An argument for PV in PVH series is that it has more functionalities,
> > but I think migration etc are just nice-to-have's in the context of this
> > security fix series.
> > 
> > I think providing a well tested solution to our users as soon as
> > possible, even if the solution has reduced functionality, is better than
> > delaying for the perfect solution.  I suggest we go with Amazon's series
> > first and produce something this week, then we seek to merge the two
> > solutions. Anthony has agreed to be on the hook to review future
> > patches. ;-)
> 
> I think this point is moot the moment vixen starts merging code from
> the pvshim branch, at which point we get some kind of Frankenstein
> shim which has more functionality than the original vixen code, but
> has neither been tested by Amazon nor by Citrix, ie: the worse of both
> scenarios.
> 
> If the vixen series has to be merged, I think the version merged
> should be the one extensively tested by Amazon, or else the testing
> point in the argument above it's just not true.
> 

Yes, if the consensus is to use the vixen series,  we should use the
well-tested patches instead of trying to merge the two implementations
in a hurry.

Wei.

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