Re: [Xen-devel] 4.2 TODO update

[George Dunlap <dunlapg@xxxxxxxxx>]

On Mon, Mar 12, 2012 at 12:11 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> This update covers two weeks since I was away last week.
>
> As usual please ping me with any updates/corrections. There are several
> things below which are in need of a volunteer to take care of them...
>
> hypervisor, blockers:
>      * domctls / sysctls set up to modify scheduler parameters, like
>        the credit1 timeslice and schedule rate. (George Dunlap, DONE)

I recently discovered a set of patches updating the PoD code in the
XenServer patchqueue which I was meant to have upstreamed but never
actually got to.  Can I add this to the "blockers" list?  It involves
changes based on some experimentation; and while I think it may be a
few days worth of work to port (with all the p2m reorganization done
after the 4.1 release), but it should be a relatively known quantity.

>
> 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:
>              * add libxl_defbool and generally try and arrange that
>                memset(foo,0,...) requests the defaults (Ian Campbell,
>                DONE)
>              * Safe fork vs. fd handling hooks. This is an API
>                addition, so maybe not required fro stable API, bit need
>                to have for 4.2? (Ian J, patches posted)
>      * xl feature parity with xend wrt driver domain support (George
>        Dunlap)
>      * More formally deprecate xm/xend. Manpage patches already in
>        tree. Needs release noting and communication around -rc1 to
>        remind people to test xl.
>      * Correct paging/sharing tools buffer mlocking (Tim, Andres, DONE)
>      * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)
>      * Domain 0 block attach & general hotplug when using qdisk backend
>        (need to start qemu as necessary etc)
>      * file:// backend performance. qemu-xen-tradition's qdisk is quite
>        slow & blktap2 not available in upstream kernels. Need to
>        consider our options:
>              * qemu-xen's qdisk is thought to be well performing but
>                qemu-xen is not yet the default. Complexity arising from
>                splitting qemu-for-qdisk out from qemu-for-dm and
>                running N qemu's.
>              * potentially fully userspace blktap could be ready for
>                4.2
>              * use /dev/loop+blkback. This requires loop driver AIO and
>                O_DIRECT patches which are not (AFAIK) yet upstream.
>              * Leverage XCP's blktap2 DKMS work.
>              * Other ideas?
>
> hypervisor, nice to have:
>      * solid implementation of sharing/paging/mem-events (using work
>        queues) (Tim Deegan, Olaf Herring et al -- is this happening? is
>        it DONE even?)
>
> tools, nice to have:
>      * Hotplug script stuff -- internal to libxl (I think, therefore I
>        didn't put this under stable API above) but still good to have
>        for 4.2? (Roger Pau Monné, patches posted)
>      * Block script support -- follows on from hotplug script (Roger
>        Pau Monné)
>      * Configure/control paging via xl/libxl (Olaf Herring, lots of
>        discussion around interface)
>      * Upstream qemu feature patches:
>              * Upstream qemu PCI passthrough support (Anthony Perard,
>                patches sent)
>              * Upstream qemu save restore (Anthony Perard, Stefano
>                Stabellini, patches sent, waiting for upstream ack)
>      * Nested-virtualisation (currently should be marked experimental,
>        likely to release that way? Consider nested-svm separate to
>        nested-vmx. Nested-svm is in better shape)
>      * Initial xl support for Remus (memory checkpoint, blackholing)
>        (Shriram, patches posted, blocked behind qemu save restore
>        patches)
>      * xl support for autospawning vncviewer (vncviewer=1 or otherwise)
>        (Nobody AFAICT)
>      * support for vif "rate" parameter (No one, AFAICT)
>
>
>
> _______________________________________________
> 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