[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] 4.2 TODO update
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,
> * 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
> * 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
> * 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