Re: [Xen-devel] 4.2 Release Plan / TODO

[George Dunlap <dunlapg@xxxxxxxxx>]

On Mon, Apr 16, 2012 at 12:31 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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?

I'm still hoping to get the PoD patches in, but we'll see.

 -George

>
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel