[Xen-devel] Xen 4.2 Release Plan / TODO

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

A day late due to the document day yesterday.

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
                                                << WE ARE HERE
2 April         -- Feature Freeze               << THIS IS NEXT WEEK
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.

Feature Freeze is this Monday. At this point we will begin deferring
patches which have not previously been posted and which are not on the
list below until Xen 4.3.

Ian.

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