From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.2 Release Plan / TODO Date: Mon, 19 Mar 2012 12:13:47 +0000 Message-ID: References: <1332154645.9223.35.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1332154645.9223.35.camel@zakaz.uk.xensource.com> 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 Mon, Mar 19, 2012 at 10:57 AM, Ian Campbell wr= ote: > So as discussed last week we now have a 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 =A0 =A0 =A0 =A0<< WE ARE= HERE > 2 April =A0 =A0 =A0 =A0 -- Feature Freeze > 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. > > Things look pretty good on the hypervisor side of things. > > The tools list is quite long but most stuff is known to be in progress > and in many cases preliminary patches are available. I think there is a > name next to everything. > > I have gather various items under a top level "xl compatibility with xm" > heading under both blocker and nice-to-have. I expect this is the area > where most bugs will be reported once we hit -rc and users start testing > this stuff in anger. > > Ian. > > 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 =A0fill with the proper cal= lbacks. (Dario > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Faggioli) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* agree & document compatibility guarantees + = associated > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0technical measures (Ian C) > =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* xl support for "rtc_timeoffset" and "localti= me" (Lin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ming, Patches posted) > =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. Nonetheless, we should still make basic functionality of xm a requirement for this release, right? I've just created a VM with a config file that worked in xl, and it complains that the hotplug scripts are not working, for example. Does that go in this todo list, or are we keeping track of bugs somewhere else? > =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) > =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 > =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. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Other ideas? > =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) > =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, patches sent, waiting for upst= ream ack) > =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 posted, blocked behind qemu save restore > =A0 =A0 =A0 =A0patches) > =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) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga= gn=E9) > > [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