[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.2 Release Plan / TODO
Roger Pau Monne wrote: > Ian Campbell 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 >> When It's Ready -- First release candidate >> Weekly -- RCN+1 until release >> >> Lots of DONE this week which is good, including one of the big three >> remaining issues (libxl_domain_suspend asyncification) has gone in >> now. Still to come are Roger's hotplug script changes (which acutally >> cover multiple items on the list) and Dario's basic NUMA support, both >> of which I think are almost there. >> >> The updated TODO list follows. >> >> If you are aware of any bugs which must/should be fixed for 4.2 then >> please reply to this thread (otherwise I may not remember to pick them >> up next week) >> >> 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. >> >> hypervisor, blockers: >> >> * [BUG] stub domains broken. HVM_PARAM_DM_DOMAIN needs to reset >> HVM_PARAM_BUFIOREQ_EVTCHN (Anthony Perard, patch sent, reviewed, >> awaiting repost) >> >> 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: >> >> * Interfaces which may need to be async: >> >> * libxl_domain_suspend. Move xc_domain_save/restore into a >> separate process (Ian Jackson, DONE). >> >> * libxl_device_{disk,nic,vkb,add,pci}_add (and >> remove). (Roger Pau MonnÃ, disk& nic included in >> calling hotplug scripts from xl, vkb >> trivial, not looked at pci yet) vkb and vfvb posted as part of my v9 hotplug series. I've given a quick look at PCI and it looks tricky, but I think some parts of the code are no longer needed (mainly the wait for the device model, because we already know Qemu is up and running when we attach PCI devices now), so it should simplify the conversion a bit. >> >> * LIBXL_NIC_TYPE enum names are confusing. (Roger, included in >> calling hotplug scripts series) >> >> * use libxl_cpumap for b_info.avail_cpus instead of an int, >> this allows setting more than 31 CPUS (Yang Z Zhang, DONE) >> >> * use an enum for VGA interface type (e.g. Cirrus, >> StdVGA). Allows for QXL support (in 4.3). (Zhou Peng, DONE) >> >> * xl compatibility with xm: >> >> * [BUG] cannot create an empty CD-ROM drive on HVM guest, >> reported by Fabio Fantoni in<4F9672DD.2080902@xxxxxxxxxx> >> >> * does not automatically try to select a (set of) node(s) on >> which to create a VM and pin its vcpus there. (Dario >> Faggioli, posted and reviewed, awaiting a repost) >> >> * [CHECK] More formally deprecate xm/xend. Manpage patches already >> in tree. Needs release noting and communication around -rc1 to >> remind people to test xl. >> >> * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau >> MonnÃ, waiting on another iteration) > > Posted v8. v9 now. > >> * Block script support -- follows on from hotplug script (Roger >> Pau MonnÃ, "just be a matter of removing an "if"") >> >> * Adjustments needed for qdisk backend to work on non-pvops Linux. >> "qemu/xendisk: set maximum number of grants to be used" (Jan >> Beulich, DONE for both qemu-xen-upstream and >> qemu-xen-traditional) >> >> * [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works. >> >> * [BUG] LIBLEAFDIR et al and libfsimage do the wrong thing on >> modern Debian/Ubuntu w/ multiarch capabilities (Matt Wilson, >> patch posted) >> >> * libxl to reject attempts to migrate a domain using upstream >> qemu, due to lack of log dirty support (Ian C, patch sent, >> reviewed, awaiting repost) >> >> hypervisor, nice to have: >> >> * PoD performance improvements (George Dunlap, DONE) >> >> * vMCE save/restore changes, to simplify migration 4.2->4.3 >> (Jinsong Liu) >> >> tools, nice to have: >> >> * xl compatibility with xm: >> >> * Accept "xl cr /dev/null param=value" to provide all config >> on the command line (W. Michael Petullo, patch posted) >> >> * libxl stable API >> >> * libxl_wait_for_free_memory/libxl_wait_for_memory_target. >> Interface needs an overhaul, related to >> locking/serialization over domain create. IanJ to add note >> about this interface being substandard but otherwise defer >> to 4.3. >> >> * Interfaces which may need to be async: >> >> * libxl_cdrom_insert. Should be easy once >> disk_{add,remove} done. This is basically a helper >> function and its functionality can be implemented in >> terms of the libxl_disk_* interfaces. If this is not >> done in time we should document as a substandard >> interface which is subject to change post 4.2. >> >> * xl.cfg(5) documentation patch for qemu-upstream >> videoram/videomem support: >> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html >> qemu-upstream doesn't support specifying videomem size for the >> HVM guest cirrus/stdvga. (but this works with >> qemu-xen-traditional). (Pasi KÃrkkÃinen) >> >> * [BUG] long stop during the guest boot process with qcow image, >> reported by Intel: >> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821 >> >> * [BUG] vcpu-set doesn't take effect on guest, reported by Intel: >> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 >> >> * Load blktap driver from xencommons initscript if available, thread at: >> <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more >> properly in 4.3. (Patch posted, discussion, plan to take simple >> xencommons patch for 4.2 and revist for 4.3) >> >> >> >> _______________________________________________ >> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |