[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Xen 4.2 Release Plan / TODO
On Tue, Apr 10, 2012 at 11:24 AM, 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.
>
> Lots more DONE this week, still a few big ticket items or items with no
> progress (that I've noticed) please let me know if the status of
> anything has changed.
>
> From next week I think I will start also tracking bugs on these lists.
> Please let me know if you have something which you feel should be listed
> here, as well as your justification for it being a blocker rather than
> "nice to fix".
Here are bugs I've found:
* 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.
* 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".
I'd make this a blocker just because it should be easy to fix and it's
pretty embarassing. This might be suitable for an enthusiastic
on-looker.
Also, since there have been other situations / reports of zombie
domains, it would be good if we could get a zombie domain detector
into the testing system to see how widespread they are.
-George
>
> 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)
> * Thinking to defer this until 4.3?
> * agree & document compatibility guarantees + associated
> technical measures (Ian C, DONE)
> * xl compatibility with xm:
> * feature parity wrt driver domain support (George Dunlap,
> DONE)
> * xl support for "rtc_timeoffset" and "localtime" (Lin
> Ming, DONE)
> * 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-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 (unlikely to be available in 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. (Useful fallback for
> some usecases
> 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. This is likely the route we will now take. Need to
> mention in release notes?
> * 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
