Re: [Xen-devel] 4.2 TODO update

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 12 Mar 2012, Ian Campbell 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)
>  
> 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)

I should be able to look into this

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

Considering how long these patches have been outstanding (years), it
might be wise to design a solution that does not require them.

In particular I think we should either go with userblktap or qdisk.
Qdisk could be a nice fallback, not too hard to code, if we don't
get userblktap in time.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel