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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-03-22 at 09:35 +0000, George Dunlap wrote:
> On Mon, Mar 19, 2012 at 10:57 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> >      * xl compatibility with xm:
> >              * feature parity wrt driver domain support (George Dunlap)
> I just discovered (while playing with driver domains) that xl is
> missing one bit of feature parity with xm for pci passthrough for PV
> guests -- and that's the "pci quirk" config file support.  I'm going
> to ask Intel if they have an interest in porting it over; I think it
> should at least be a "nice-to-have", and it may be a low-level
> blocker, as a lot of devices won't work passed through without it.

This is the stuff in tools/python/xen/xend/server/pciquirk.py ?

pciback in upstream doesn't mention "quirk" which suggests no support
for the necessary sysfs node either?

tools/examples/xend-pci-quirks.sxp  seems to only have a quirk for a
single card?

I don't think we want to implement an SXP parser for xl/libxl so if this
is reimplemented I think a different format should be used.

Anyway, I'll put this onto the list.

Ian

> 
> >              * xl support for "rtc_timeoffset" and "localtime" (Lin
> >                Ming, Patches posted)
> >      * 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)
> >      * 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?
> >      * Improved Hotplug script support (Roger Pau MonnÃ, patches
> >        posted)
> >      * Block script support -- follows on from hotplug script (Roger
> >        Pau MonnÃ)
> >
> > hypervisor, nice to have:
> >      * solid implementation of sharing/paging/mem-events (using work
> >        queues) (Tim Deegan, Olaf Herring et al -- patches posted)
> >              * "The last patch to use a waitqueue in
> >                __get_gfn_type_access() from Tim works.  However, there
> >                are a few users who call __get_gfn_type_access with the
> >                domain_lock held. This part needs to be addressed in
> >                some way."
> >      * Sharing support for AMD (Tim, Andres).
> >      * PoD performance improvements (George Dunlap)
> >
> > tools, nice to have:
> >      * Configure/control paging via xl/libxl (Olaf Herring, lots of
> >        discussion around interface, general consensus reached on what
> >        it should look like)
> >      * 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 "experimental". Likely to
> >        release that way.
> >              * Nested SVM. Tested in a variety of configurations but
> >                still some issues with the most important use case (w7
> >                XP mode) [0]  (Christoph Egger)
> >              * Nested VMX. Needs nested EPT to be genuinely useful.
> >                Need more data on testedness etc (Intel)
> >      * Initial xl support for Remus (memory checkpoint, blackholing)
> >        (Shriram, patches posted, blocked behind qemu save restore
> >        patches)
> >      * xl compatibility with xm:
> >              * xl support for autospawning vncviewer (vncviewer=1 or
> >                otherwise) (Goncalo Gomes)
> >              * support for vif "rate" parameter (Mathieu GagnÃ)
> >
> > [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html
> >
> >
> > _______________________________________________
> > 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