Re: [Xen-devel] Xen 4.5 development update

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 27 May 2014, 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>

Interrupt latency reduction (no maintenance interrupts): 100%


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