Re: [Xen-devel] Xen 4.5 development update

[Lars Kurth <lars.kurth@xxxxxxx>]

Adding Artem from Globallogic to that thread on request
Lars

On 27/05/2014 19:06, konrad.wilk@xxxxxxxxxx wrote:

Below is a summary of the projects / features being worked on for the 4.5
time frame that I had been gathering.

It is not complete! I would like folks input if I had missed something
or screwed up. Will also talk at Xen Hackahon about this and take a look
at  http://wiki.xen.org/wiki/Xen_Roadmap/4.4 to see which of the
items there should move over.

The tentative feature freeze is scheduled for September 10th,
which is months away.  With that in mind, I think it's time to take
stock of the development, so we know whether to ask for more help or divert
resources.

For items involving code hosted on the Xen.org site (including qemu-xen),
that means a likelihood of having the feature code-complete and mostly
working by the feature freeze.  (It's OK if there are still bugs to be
worked out.)  For items in Linux, I think it would mean having items on track
to make it into the kernel released just after the scheduled 4.5 time frame.
Not sure what that means for libvirt. :-)

For items involving code hosted on the Xen.org site (including qemu-xen),
that means a likelihood of having the feature code-complete and mostly
working by the feature freeze.  (It's OK if there are still bugs to be
worked out.)  For items in Linux, I think it would mean having items on track
to make it into the kernel released just after the scheduled 4.5 time frame.
Not sure what that means for libvirt. :-)

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature Freeze: 10th September 2014
* First RC: 10th October
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

= Prognosis =

The prognosis is a numerical value of the likehood of the feature/code
making it in the code-base.

If folks prefer the fair, good, excellent marker I can switch over to
that.

= Open =

* Andrew Cooper  Prognosis:   100 %
    libx{c,l} error handling cleanup 
    New migration.
    cpuid leveling

* Andrew Benniest  Prognosis:   100 %
    Netback multiqueue

* Arianna Avanzini  Prognosis:   100 %
    block multiqueue
    XEN_DOMCTL_memory_mapping hypercall for ARM

* Elena Ufimtseva  Prognosis:   0 %
    vNUMA in Xen
    vNUMA in Linux

* Boris Ostrovsky  Prognosis:   100 %
    VPMU - 'perf' support in Xen
    VPMU - 'perf' support in Linux
    vAPIC in PVHVM guests

* Bob Liu  Prognosis:   100 %
    tmem cleanups/fixes
    1TB slow destruction

* Dario Faggioli  Prognosis:   0 %
    Soft affinity for vcpus (was NUMA affinity for vcpus)

* Matt Wilson  Prognosis:   0 %
    HVM guest NUMA

* Don Slutz  Prognosis:   100 %
    Bigger PCI hole in QEMU 
    Re-write of HPET

* David Vrabel:  Prognosis:   100 %
    New migration.

* Daniel Kiper  Prognosis:   100 %
    GRUB2 multiboot2
    Xen multiboot2 support
    Linux pvops of Xen EFI hypercall support
    libxl/xl - xm compatibility mode for mem-max and mem-set;
    Rearrange and cleanup installation destination directories (/var -> var/lib/xen)

* George Dunlap:  Prognosis:   100 %
    Default to credit2
    >  cpu pinning, numa affinity and cpu reservation

* Roger Pau Monné  Prognosis:   100 %
    Xen PVH dom0
    PVH FreeBSD dom0

* Konrad Rzeszutek Wilk  Prognosis:   30 %
    NUMA memory scrubbing
    Performance fixes for PCI passthrough

* Kelly Zytaruk  Prognosis:   100 %
    AMD Radeon PCI GPU passthrough

* Chen, Tiejun  Prognosis:   100 %
    Intel IGD PCI GPU passthrough

* Mukesh Rathor  Prognosis:   100 %
    Xen PVH dom0
    Linux PVH dom0

* Wei Liu  Prognosis:   100 %
    Adding missing 'xend' features in libxl
    xl list -l on a dom0-only system
    xl list -l doesn't contain tty console port
    xl: passing more defaults in configuration in xl.conf
    >  There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

* Ian Campbel  Prognosis:   100 %
    OSSTest: libvirt
    OSSTest: upstream QEMU

* Ian Jackson  Prognosis:   100 %
    xl does not handle migrate interruption gracefully
    >  If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains

* Stefano Stabellini  Prognosis:   100 %
    <NONE>

* Julien Grall  Prognosis:   100 %
    ARM IOMMU support

* Malcolm Crossley  Prognosis:   100 %
    IOMMU ABI for guests to map their DMA regions

* Zoltan Kiss  Prognosis:   100 %
    Netback grant table manipulations
    "Short" grant copy (just header) of packets. 

* Feng Wu  Prognosis:   100 %
    SMAP
    alternative_asm in Xen

* Zhang, Yang Z  Prognosis:   100 %
    dirty vram / IOMMU bug

* Paul Durrant  Prognosis:   100 %
    ioreq-server, aka secondary emulators

* Jan Beulich  Prognosis:   100 %
    Stability

* Olaf Hering  Prognosis:   100 %
    libvirt and xl discard support, so that libvirt can start using it
    pvscsi should be targeted for 4.5, a prototype exists
    live migration knobs, there is no suitable code yet, just ideas

* Joe Doe aka not assigned to anybody  Prognosis:   0 %
    PoD fixes
    TLB flushing without locks in Xen
    xl does not support specifying virtual function for passthrough device
    >  http://bugs.xenproject.org/xen/bug/22
    PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
    >  http://bugs.xenproject.org/xen/bug/28

_______________________________________________
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