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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Wed, Jan 10, 2018 at 4:27 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> 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.

I agree, and that's v1.

Regards,

Anthony Liguori

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

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