From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: 4.2 Release Plan / TODO Date: Mon, 16 Apr 2012 15:20:33 +0100 Message-ID: References: <1334575910.14560.146.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: <1334575910.14560.146.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, Apr 16, 2012 at 12:31 PM, 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. > > 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: > =A0 =A0 =A0* [BUG] Zombie driver domains. =A0There's a bug where PV guest= s with > =A0 =A0 =A0 =A0devices passed through with xl hang around as "zombies", w= ith > =A0 =A0 =A0 =A0one outstanding page reference. =A0I think this should rea= lly be a > =A0 =A0 =A0 =A0blocker. I'm working on this at the moment (George Dunlap). > =A0 =A0 =A0 =A0 =A0 =A0 =A0* One of several recent reports of Zombie doma= ins, which > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0may or may not be all related. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* List as hypervisor for now, but may turn out= to be a > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tools issue. > > 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. [...] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Deferred until 4.3. We think= this functionality > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0can be added without impac= ting API stability. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_wait_for_free_memory/libxl_wait_for_me= mory_target. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Interface needs an overhaul, related to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0locking/serialization over domain create (= see above). > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IanJ to add note about this interface bein= g substandard > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0but otherwise defer to 4.3. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_{FOO}_exec. Should return a data struc= ture > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0declaring what to do, not fork and exec th= emselves. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0However we can defer this until 4.3. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_*_path. Majority made internal, only c= onfigdir and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0lockdir remain public (used by xl). Good e= nough? > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Interfaces which may need to be async: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_suspend. Nobody= has looked at these > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at all. A volunteer would = be appreciated. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_create_{new,res= tore} -- IanJ has > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches as part of event s= eries. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_{shutdown,reboo= t}. These are "fast" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0functions and there do not= need to be async. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(So, DONE with no action r= equired) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_domain_core_dump. Can = take a dummy ao_how > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and remain synchronous int= ernally. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_{disk,nic,vkb,a= dd}_add (and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remove?). Roger Pau Monn= =E9 fixes disk as part of > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hotplug script series and = adds infrastructure > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0which should make the othe= rs trivial. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_cdrom_insert. Should b= e easy once > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0disk_{add,remove} done, Ia= nJ to look at. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_disk_local_{att= ach,detach}. Become > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0internal as part of Stefan= o's domain 0 disk > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attach series. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_device_pci_{add,remove= }. Less trivial than > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the others. A volunteer wo= uld be appreciated. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_xen_console_*. No inte= rface for waiting > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and each call just dumps a= bit more of the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ring , so is fast. Nothing= to do here (therefore > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_xen_tmem_*. All functi= ons are "fast" and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0therefore no async needed.= Exception is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmem_destroy which Dan Mag= enheimer says is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0obsolete and can just be r= emoved. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* libxl_fork -- IanJ's event s= eries removes all > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0users of this. > =A0 =A0 =A0* [BUG] Manually ballooning dom0. =A0xl mem-set 0 [foo] fails = with > =A0 =A0 =A0 =A0"libxl: error: libxl.c:2569:libxl_set_memory_target: canno= t get > =A0 =A0 =A0 =A0memory info from /local/domain/0/memory/static-max: No suc= h file > =A0 =A0 =A0 =A0or directory". This might be suitable for an enthusiastic > =A0 =A0 =A0 =A0on-looker. (George Dunlap, in the absence of said onlooker) > =A0 =A0 =A0* xl compatibility with xm: > =A0 =A0 =A0 =A0 =A0 =A0 =A0* None remaining? > =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. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* qemu-xen-traditional and upstream qemu-xen p= erformance > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0has been improved and is now satisfactory. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* Xen 4.2 will prefer blktap2 if a kernel modu= le is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0available (e.g. older dom0 kernel or DKMS = provided > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kernel module) and will fallback to qemu q= disk if no > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0blktap2 is available. > =A0 =A0 =A0 =A0 =A0 =A0 =A0* There will be no userspace "blktap3" for Xen= 4.2 > =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) > > 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: > =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, waiting on libxl side of qemu upstream save/rest= ore) > =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, waiting on new = version of > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0patches) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* support for vif "rate" parameter (Mathieu Ga= gn=E9, waiting > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0on new version of patches) > =A0 =A0 =A0 =A0 =A0 =A0 =A0* expose PCI back "permissive" parameter (Geor= ge Dunlap, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DONE) > > [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