[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Xen 4.2 Release Plan / TODO
Plan for a 4.2 release: http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html The time line is as follows: 19 March -- TODO list locked down 2 April -- Feature Freeze << WE ARE HERE Mid/Late April -- First release candidate Weekly -- RCN+1 until it is ready The updated TODO list follows. Per the release plan a strong case will now have to be made as to why new items should be added to the list, especially as a blocker, rather than deferred to 4.3. We have now entered Feature Freeze. Patches which have been posted before or which address something on the list below are still acceptable (for now, we will gradually be getting stricter about this), everything else will be deferred until 4.3 by default. hypervisor, blockers: * NONE? tools, blockers: * libxl stable API -- we would like 4.2 to define a stable API which downstream's can start to rely on not changing. Aspects of this are: * Safe fork vs. fd handling hooks. Involves API changes (Ian J, patches posted) * locking/serialization, e.g., for domain creation. As of now, nothing is provided for this purpose, and downstream toolstacks have to put their own mechanisms in place. E.g., xl uses a fcntl() lock around the whole process of domain creation. It should OTOH be libxl job to offer a proper set of hooks --placed at the proper spots during the domain creation process-- for the downstreams to fill with the proper callbacks. (Dario Faggioli) * agree & document compatibility guarantees + associated technical measures (Ian C, patches posted) * xl compatibility with xm: * feature parity wrt driver domain support (George Dunlap) * xl support for "rtc_timeoffset" and "localtime" (Lin Ming, Patches posted) * More formally deprecate xm/xend. Manpage patches already in tree. Needs release noting and communication around -rc1 to remind people to test xl. * Domain 0 block attach & general hotplug when using qdisk backend (need to start qemu as necessary etc) (Stefano S) * file:// backend performance. qemu-xen-tradition's qdisk is quite slow & blktap2 not available in upstream kernels. Need to consider our options: * qemu-xen's qdisk is thought to be well performing but qemu-xen is not yet the default. Complexity arising from splitting qemu-for-qdisk out from qemu-for-dm and running N qemu's. * potentially fully userspace blktap could be ready for 4.2 * use /dev/loop+blkback. This requires loop driver AIO and O_DIRECT patches which are not (AFAIK) yet upstream. * Leverage XCP's blktap2 DKMS work. * Other ideas? * In general we should recommend blkback (e.g. with LVM) since it always out performs other solutions, although at the expense of flexibility regarding image formats. Stefano has done a lot of work here and has proposed some performance improvements for qdisk in both qemu-xen and qemu-xen-traditional which make them a plausible alternative for Xen 4.2. * Improved Hotplug script support (Roger Pau MonnÃ, patches posted) * Block script support -- follows on from hotplug script (Roger Pau MonnÃ) hypervisor, nice to have: * solid implementation of sharing/paging/mem-events (using work queues) (Tim Deegan, Olaf Herring et al -- patches posted) * "The last patch to use a waitqueue in __get_gfn_type_access() from Tim works. However, there are a few users who call __get_gfn_type_access with the domain_lock held. This part needs to be addressed in some way." * Sharing support for AMD (Tim, Andres). * PoD performance improvements (George Dunlap) tools, nice to have: * Configure/control paging via xl/libxl (Olaf Herring, lots of discussion around interface, general consensus reached on what it should look like. Olaf has let me know that he is probably not going to have time to do this for 4.2, will likely slip to 4.3 unless someone else want to pick up that work) * Upstream qemu feature patches: * Upstream qemu PCI passthrough support (Anthony Perard, patches sent) * Upstream qemu save restore (Anthony Perard, Stefano Stabellini, qemu patches applied, waiting for libxl etc side which has been recently reposted) * Nested-virtualisation. Currently "experimental". Likely to release that way. * Nested SVM. Tested in a variety of configurations but still some issues with the most important use case (w7 XP mode) [0] (Christoph Egger) * Nested VMX. Needs nested EPT to be genuinely useful. Need more data on testedness etc (Intel) * Initial xl support for Remus (memory checkpoint, blackholing) (Shriram, patches reposted recently, was blocked behind qemu save restore patches which are now in) * xl compatibility with xm: * xl support for autospawning vncviewer (vncviewer=1 or otherwise) (Goncalo Gomes, patches posted) * support for vif "rate" parameter (Mathieu GagnÃ, patches posted) * expose PCI back "permissive" parameter (George Dunlap) [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |