Re: Xen 4.4 development update: Code freezing point reached

["Roger Pau Monné" <roger.pau@citrix.com>]

On 18/11/13 19:19, George Dunlap wrote:
> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.4
> 
> (And I actually updated the wiki this time.)
> 
> The code "freezing point" is today; which means that starting today
> non-bug fixes need a freeze exception to be included.
> 
> Remember our goal for the release:
>  1. A bug-free release
>  2. An awesome release
>  3. An on-time release
> 
> Accepting a new feature may make Xen more awesome; but it also
> introduces a risk that it will introduce more bugs.  That bug may be
> found before the release (threatening #3), or it may not be found
> until after the release (threatening #1).  Each freeze exception
> request will attempt to balance the benefits (how awesome the
> exception is) vs the risks (will it cause the release to slip, or
> worse, cause a bug which goes un-noticed into the final release).
> 
> The idea is that today we will be pretty permissive, but that we will
> become progressively more conservative until the first RC, which is
> scheduled for 3 weeks' time (6 December).  After that, we will only
> accept bug fixes.
> 
> Bug fixes can be checked in without a freeze exception throughout the
> code freeze, unless the maintianer thinks they are particularly high
> risk.  In later RC's, we may even begin rejecting bug fixes if the
> broken functionality is small and the risk to other functionality is
> high.
> 
> Features which are currently marked "experimental" or do not at the
> moment work at all cannot be broken really; so changes to code only
> used by those features should be able to get a freeze exception
> easily.  (Tianocore is something which would probably fall under
> this.)
> 
> Features which change or add new interfaces which will need to be
> supported in a backwards-compatible way (for instance, vNUMA) will
> need freeze exceptions to make sure that the interface itself has
> enough time to be considered stable.
> 
> These are guidelines and principles to give you an idea where we're
> coming from; if you think there's a good reason why making an
> exception for you will help us achieve goals 1-3 above better than not
> doing so, feel free to make your case.
> 
> = Timeline =
> 
> Here is our current timeline based on a 6-month release:
> 
> * Feature freeze: 18 October 2013
> * Code freezing point: 18 November 2013 <== WE ARE HERE
> * First RC: 6 December 2013
> * Release: 21 January 2014
> 
> Last updated: 18 November 2016
> 
> == Completed  ==
> 
> * Event channel scalability (FIFO event channels)
> 
> * Non-udev scripts for driver domains (non-Linux driver domains)
> 
> * Multi-vector PCI MSI (Hypervisor side)
> 
> * Improved Spice support on libxl
>  - Added Spice vdagent support
>  - Added Spice clipboard sharing support
> 
> * PHV domU (experimental only)
> 
> * Guest EFI booting (tianocore)
> 
> * kexec
> 
> * Testing: Xen on ARM
> 
> * Update to SeaBIOS 1.7.3.1
> 
> * pvgrub2 checked into grub upstream

* Driver domain userspace daemon.

> 
> == Resolved since last update ==
> 
> * credit scheduler doesn't update other fields when tslice updated from sysctl
> 
> == Open ==
> 
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted; latest patches need testing
> 
> * Race in PV shutdown between tool detection and shutdown watch
>  > http://www.gossamer-threads.com/lists/xen/devel/282467
>  > Nothing to do with ACPI
>  status: Patches posted
> 
> * Supposed regression from a3513737 ("x86: allow guest to set/clear
>  > MSI-X mask bit (try 2)"), as per
>  > http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html.
> 
> * qemu-traditional mis-parses host bus 8 as 0
>  > http://bugs.xenproject.org/xen/bug/15
> 
> * xen_platform_pci=0 doesn't work with qemu-xen
>  > http://bugs.xenproject.org/xen/bug/20
> 
> * xl does not support specifying virtual function for passthrough device
>  > http://bugs.xenproject.org/xen/bug/22
> 
> * xl does not handle migrate interruption gracefully
>   > If you start a localhost migrate, and press "Ctrl-C" in the middle,
>   > you get two hung domains
> 
> * libxl / xl does not handle failure of remote qemu gracefully
>   > Easiest way to reproduce:
>   >  - set "vncunused=0" and do a local migrate
>   >  - The "remote" qemu will fail because the vnc port is in use
>   > The failure isn't the problem, but everything being stuck afterwards is
> 
> * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
> capable HPETs)
>   owner: andyh@citrix
>   status: patches posted, undergoing review iteration.
> 
> == Backlog ==
> 
> === Testing coverage ===
> 
> * new libxl w/ previous versions of xl
>  @IanJ
> 
> * Host S3 suspend
>  @bguthro, @dariof
> 
> * Default [example] XSM policy
>  @Stefano to ask Daniel D
> 
> * Storage driver domains
>  @roger
> 
> * HVM pci passthrough
>  @anthony
> 
> * PV pci passthrough
>  @konrad (or @george if he gets to it first)
> 
> * Network driver domains
>  @George
> 
> * Nested virt?
>  @intel (chased by George)
> 
> * Fix SRIOV test (chase intel)
>  @ianj
> 
> * Fix bisector to e-mail blame-worthy parties
>  @ianj
> 
> * Fix xl shutdown
>   @ianj
> 
> * stub domains
>   @athony
> 
> * performance benchmarks
>   @dario
> 
> === Meta-items (composed of other items) ===
> 
> * Meta: PVIO NUMA improvements
>  - NUMA affinity for vcpus (4.4 possible)
>  - PV guest NUMA interface (4.4 possible)
>  - Sensible dom0 NUMA layout
>  - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>  - NUMA-aware ballooning
> 
> * xend still in tree (x)
>  - xl list -l on a dom0-only system
>  - xl list -l doesn't contain tty console port
>  - xl Alternate transport support for migration*
>  - xl PVSCSI support
>  - xl PVUSB support
> 
> === Big ticket items ===
> 
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle, george@citrix
>   status (Linux): Acked, waiting for ABI to be nailed down
>   status (Xen): Initial version checked in, still nailing down interface
> 
> * Update to qemu 1.6
>   owner: Anthonyper
>   status: In staging, still working out a bug in the VMX code
> 
> * Live Migration Support
>   owner: Jaeyong Yoo <jaeyong.yoo@samsung.com>
>   status: v5 posted, looking good for code freeze
> 
> * ARM64 guest
>   owner: IanC
>   status: v3 posted, v4 in progress. looking good.
> 
> * SWIOTLB (kernel side thing)
>   owner: Stefano
>   status: Pull request sent.
> 
> * soft affinity for vcpus (was NUMA affinity for vcpus)
>     owner: Dario
>     status: v2 posted
> 
> * PV guest NUMA interface
>     owner: Elena
>     status: v3 posted
> 
> * libvirt/libxl integration (external)
>  - owner: jfehlig@suse, dario@citrix
>  - patches posted (should be released before 4.4)
>   - migration
>   - PCI pass-through
>  - In progress
>   - integration w/ libvirt's lock manager
>   - improved concurrency
> 
> * xl USB pass-through for HVM guests using Qemu USB emulation
>   prognosis: Good if extended
>   owner: George
>   status: v6 patch series posted
> 
> * libxl: Spice usbredirection support for upstream qemu
>  owner: fabio@M2R
>  status: I'll post new patch version shortly
> 
> * libxl: usb2 and usb3 controller support for upstream qemu
>  owner: fabio@M2R
>  status: patch v5 posted, tested and working, awaiting reviews
> 
> * libxl network buffering support for Remus
>    @shriram
>    status: patches posted
>    prognosis: fair
> 
> * Disk: indirect descriptors
>    owner: roger@citrix
>    status: Linux side in 3.11, Xen-side patch posted
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>