[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.4 development update: Code freezing point reached
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@xxxxxxxxxxx> > 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@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |