[Xen-devel] 4.2 Release Plan / TODO

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

A bunch of new items have been added to the list, mainly due to Ian
Jacksons review of the libxl API for stability. I believe these are
mostly under control. Some of these are going to be immediately deferred
to 4.3 but I have included them in this week's list to allow the
opportunity for feedback.

Some of the new items are unclaimed. Volunteers would be much
appreciated.

As discussed last week I have added known bugs to the lists below.
Please refer me to any should or must be fixed bugs (best way it by
responding to this mail with a pointer so my threading mailer will track
it for next week).

hypervisor, blockers:
      * [BUG] Zombie driver domains.  There's a bug where PV guests with
        devices passed through with xl hang around as "zombies", with
        one outstanding page reference.  I think this should really be a
        blocker. I'm working on this at the moment (George Dunlap).
              * One of several recent reports of Zombie domains, which
                may or may not be all related.
              * List as hypervisor for now, but may turn out to be a
                tools issue.
 
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. [...]
                      * Deferred until 4.3. We think this functionality
                        can be added without impacting API stability.
              * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
                Interface needs an overhaul, related to
                locking/serialization over domain create (see above).
                IanJ to add note about this interface being substandard
                but otherwise defer to 4.3.
              * libxl_{FOO}_exec. Should return a data structure
                declaring what to do, not fork and exec themselves.
                However we can defer this until 4.3.
              * libxl_*_path. Majority made internal, only configdir and
                lockdir remain public (used by xl). Good enough?
              * Interfaces which may need to be async:
                      * libxl_domain_suspend. Nobody has looked at these
                        at all. A volunteer would be appreciated.
                      * libxl_domain_create_{new,restore} -- IanJ has
                        patches as part of event series.
                      * libxl_domain_{shutdown,reboot}. These are "fast"
                        functions and there do not need to be async.
                        (So, DONE with no action required)
                      * libxl_domain_core_dump. Can take a dummy ao_how
                        and remain synchronous internally.
                      * libxl_device_{disk,nic,vkb,add}_add (and
                        remove?). Roger Pau Monnà fixes disk as part of
                        hotplug script series and adds infrastructure
                        which should make the others trivial.
                      * libxl_cdrom_insert. Should be easy once
                        disk_{add,remove} done, IanJ to look at.
                      * libxl_device_disk_local_{attach,detach}. Become
                        internal as part of Stefano's domain 0 disk
                        attach series.
                      * libxl_device_pci_{add,remove}. Less trivial than
                        the others. A volunteer would be appreciated.
                      * libxl_xen_console_*. No interface for waiting
                        and each call just dumps a bit more of the
                        ring , so is fast. Nothing to do here (therefore
                        DONE)
                      * libxl_xen_tmem_*. All functions are "fast" and
                        therefore no async needed. Exception is
                        tmem_destroy which Dan Magenheimer says is
                        obsolete and can just be removed.
                      * libxl_fork -- IanJ's event series removes all
                        users of this.
      * [BUG] Manually ballooning dom0.  xl mem-set 0 [foo] fails with
        "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get
        memory info from /local/domain/0/memory/static-max: No such file
        or directory". This might be suitable for an enthusiastic
        on-looker. (George Dunlap, in the absence of said onlooker)
      * xl compatibility with xm:
              * None remaining?
      * 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, patches
        posted)
      * file:// backend performance.
              * qemu-xen-traditional and upstream qemu-xen performance
                has been improved and is now satisfactory.
              * Xen 4.2 will prefer blktap2 if a kernel module is
                available (e.g. older dom0 kernel or DKMS provided
                kernel module) and will fallback to qemu qdisk if no
                blktap2 is available.
              * There will be no userspace "blktap3" 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)

It seems that none of the above are going to happen for 4.2?

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, waiting on libxl side of qemu upstream save/restore)
      * xl compatibility with xm:
              * xl support for autospawning vncviewer (vncviewer=1 or
                otherwise) (Goncalo Gomes, waiting on new version of
                patches)
              * support for vif "rate" parameter (Mathieu GagnÃ, waiting
                on new version of patches)
              * expose PCI back "permissive" parameter (George Dunlap,
                DONE)

[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