From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.2 Release Plan / TODO Date: Thu, 12 Apr 2012 10:56:34 +0100 Message-ID: References: <1334053490.12209.176.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1334053490.12209.176.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Apr 10, 2012 at 11:24 AM, Ian Campbell wr= ote: > 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 =A0 =A0 =A0 =A0-- TODO list locked down > 2 April =A0 =A0 =A0 =A0 -- Feature Freeze > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 << WE ARE HERE > Mid/Late April =A0-- First release candidate > Weekly =A0 =A0 =A0 =A0 =A0-- 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: > =A0 =A0 =A0* NONE? > > tools, blockers: > =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API > =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe= cts of > =A0 =A0 =A0 =A0this are: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Safe fork vs. fd handling hooks. Involves AP= I changes > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Ian J, patches posted) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* locking/serialization, e.g., for domain crea= tion. As of > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0now, =A0nothing is provided for this purpo= se, and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstream toolstacks have to put their ow= n mechanisms > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in place. E.g., xl uses a fcntl() lock aro= und the whole > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0process of domain creation. It should OTOH= be libxl job > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to offer a proper set of hooks --placed at= the proper > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0spots during the domain creation process--= for the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0downstreams to fill with the proper callba= cks. (Dario > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Faggioli) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Thinking to defer this until= 4.3? > =A0 =A0 =A0 =A0 =A0 =A0 =A0* agree & document compatibility guarantees + = associated > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0technical measures (Ian C, DONE) > =A0 =A0 =A0* xl compatibility with xm: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* feature parity wrt driver domain support (Ge= orge Dunlap, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for "rtc_timeoffset" and "localti= me" (Lin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ming, DONE) > =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in > =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to > =A0 =A0 =A0 =A0remind people to test xl. > =A0 =A0 =A0* Domain 0 block attach & general hotplug when using qdisk bac= kend > =A0 =A0 =A0 =A0(need to start qemu as necessary etc) (Stefano S, patches > =A0 =A0 =A0 =A0posted) > =A0 =A0 =A0* file:// backend performance. qemu-xen-tradition's qdisk is q= uite > =A0 =A0 =A0 =A0slow & blktap2 not available in upstream kernels. Need to > =A0 =A0 =A0 =A0consider our options: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen's qdisk is thought to be well perfo= rming but > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0qemu-xen is not yet the default. Complexit= y arising from > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0splitting qemu-for-qdisk out from qemu-for= -dm and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0running N qemu's. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* potentially fully userspace blktap could be = ready for > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04.2 (unlikely to be available in 4.2) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* use /dev/loop+blkback. This requires loop dr= iver AIO and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0O_DIRECT patches which are not (AFAIK) yet= upstream. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Leverage XCP's blktap2 DKMS work. (Useful fa= llback for > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some usecases > =A0 =A0 =A0 =A0Stefano has done a lot of work here and has proposed some > =A0 =A0 =A0 =A0performance improvements for qdisk in both qemu-xen and > =A0 =A0 =A0 =A0qemu-xen-traditional which make them a plausible alternati= ve for > =A0 =A0 =A0 =A0Xen 4.2. This is likely the route we will now take. Need to > =A0 =A0 =A0 =A0mention in release notes? > =A0 =A0 =A0* Improved Hotplug script support (Roger Pau Monn=E9, patches > =A0 =A0 =A0 =A0posted) > =A0 =A0 =A0* Block script support -- follows on from hotplug script (Roger > =A0 =A0 =A0 =A0Pau Monn=E9) > > hypervisor, nice to have: > =A0 =A0 =A0* solid implementation of sharing/paging/mem-events (using work > =A0 =A0 =A0 =A0queues) (Tim Deegan, Olaf Herring et al -- patches posted) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* "The last patch to use a waitqueue in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0__get_gfn_type_access() from Tim works. = =A0However, there > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0are a few users who call __get_gfn_type_ac= cess with the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain_lock held. This part needs to be ad= dressed in > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0some way." > =A0 =A0 =A0* Sharing support for AMD (Tim, Andres). > =A0 =A0 =A0* PoD performance improvements (George Dunlap) > > tools, nice to have: > =A0 =A0 =A0* Configure/control paging via xl/libxl (Olaf Herring, lots of > =A0 =A0 =A0 =A0discussion around interface, general consensus reached on = what > =A0 =A0 =A0 =A0it should look like. Olaf has let me know that he is proba= bly > =A0 =A0 =A0 =A0not going to have time to do this for 4.2, will likely sli= p to > =A0 =A0 =A0 =A04.3 unless someone else want to pick up that work) > =A0 =A0 =A0* Upstream qemu feature patches: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu PCI passthrough support (Antho= ny Perard, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches sent) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Upstream qemu save restore (Anthony Perard, = Stefano > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stabellini, qemu patches applied, waiting = for libxl etc > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0side which has been recently reposted) > =A0 =A0 =A0* Nested-virtualisation. Currently "experimental". Likely to > =A0 =A0 =A0 =A0release that way. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested SVM. Tested in a variety of configura= tions but > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0still some issues with the most important = use case (w7 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0XP mode) [0] =A0(Christoph Egger) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Nested VMX. Needs nested EPT to be genuinely= useful. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Need more data on testedness etc (Intel) > =A0 =A0 =A0* Initial xl support for Remus (memory checkpoint, blackholing) > =A0 =A0 =A0 =A0(Shriram, patches reposted recently, was blocked behind qe= mu > =A0 =A0 =A0 =A0save restore patches which are now in) > =A0 =A0 =A0* xl compatibility with xm: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* xl support for autospawning vncviewer (vncvi= ewer=3D1 or > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0otherwise) (Goncalo Gomes, patches posted) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga= gn=E9, patches > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0posted) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor= ge Dunlap) > > [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel