[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.2 TODO / Release



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
Mid/Late May    -- First release candidate
Weekly          -- RCN+1 until it is ready

It seems pretty obvious at this stage that we are not going to be
doing an RC in Mid/Late May. The big remaining items are being
actively worked on and are quite well understood. I've also done a
pass through the tools blockers list and have proposed moving some
items to the Nice To Have list.

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.

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)

Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.

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:

         * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
           Interface needs an overhaul, related to
           locking/serialization over domain create (deferred to
           4.3). IanJ to add note about this interface being
           substandard but otherwise defer to 4.3. Will move to Nice To
           Have's next week.

         * libxl_*_path. Majority made internal, only configdir and
           lockdir remain public (used by xl). (IanC, to consider
           moving the two reamining into xl instead of libxl, will move
           to Nice To Have's next week)

         * Interfaces which may need to be async:

             * libxl_domain_suspend. Move xc_domain_save/restore into a
               separate process (IanJ, RFC posted, work ongoing).

             * libxl_device_{disk,nic,vkb,add,pci}_add (and
               remove?). Roger Pau Monnà fixes disk as part of hotplug
               script series and adds infrastructure which should make
               the others trivial. (Roger, WIP)

Patches posted (in the hotplug series) to make disk and nic async (both addition and deletion). Once that is in, vfb and vkb are quite trivial. I'm not sure about PCI since I haven't looked at it.

You can also add:

* libxl_domain_destroy: convert to async. Mostly done since it will go in with my hotplug script series and the disk/nic add/remove.


             * libxl_cdrom_insert. Should be easy once
               disk_{add,remove} done. Nobody is looking at this? This
               is basically a helper function and its functionality can
               be implemented in terms of the libxl_disk_*
               interfaces. We could therefore consider marking this
               function as substandard and subject to change in the
               future. We could also consider simply moving it into xl
               as a helper function and revisting for 4.3.

     * 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, patches posted)

         * `cpus=[2,3]` to select specific mapping vcpu0-->pcpu2,
           vcpu1-->pcpu3 as xm does. (Dario Faggioli, DONE)

     * [BUG] Spurious CPU params error message when starting a domain,
       e.g. "Cpu weight out of range, valid values are within range
       from 1 to 65535". (Ian C, patches posted, need final decision on
       "one struct" or "multiple struct" libxl API for sched params)

     * 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, people seem happy bar the code motion)

     * Improved Hotplug script support (Roger Pau MonnÃ, patches
       posted, nearing completion?)

I would call this "calling hotplug scripts from xl", "improved hotplug script support" seems quite vague. Yes, I think they are quite done, and people seems to be happy with that.

I also have the NetBSD support in my patch queue, waiting for the Linux support to go in (since it will be pointless to have to repost the NetBSD series every time the previous one changes).


     * Block script support -- follows on from hotplug script (Roger
       Pau MonnÃ)

This will just be a matter of removing an "if" that's preventing libxl from using custom hotplug scripts for disks.

     * Adjustments needed for qdisk backend to work on non-pvops Linux.
       (Jan Beulich)

* qemu-upstream for NetBSD: I'm currently working on this. It compiles but VGA memory mapping seems to be wrong, and qemu gets a segfault when trying to write to it.

hypervisor, nice to have:

     * PoD performance improvements (George Dunlap)

     * IRQ problem for which debugging code got added by c/s
       24707:96987c324a4f. I have a tentative adjustment to this which
       I would hope to at least eliminate the bad consequences of
       crashing the hypervisor (converting the unsolicited
       PIC-originated IRQ into a spurious one). I'll submit as soon as
       I got to test this a little, particularly also on an old box
       without APIC. (Jan Beulich, DONE)

tools, nice to have:

     * xl compatibility with xm:

         * None remain

     * libxl: Add API to retrieve domain console tty (Bamvor Jian
       Zhang, patches posted)

     * 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)



_______________________________________________
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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.