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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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 ?

Ian.

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