[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 4.3 Planning: Taking stock

On Wed, Jan 23, 2013 at 4:32 PM, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
== Finished features ==

* Default to QEMU upstream (partial)
 - pci pass-thru (external)
 - enable dirtybit tracking during migration (external)
 - xl cd-{insert,eject} (external)
* Persistent grants for blk (Linux)
* Allow XSM to override IS_PRIV checks in the hypervisor
* CPUID-based idle (don't rely on ACPI info f/ dom0)
* Serial console improvements

== Features on-track ==

* PVH mode (Xen & Linux)
* Event channel scalability
* ARM v7 server port
* NUMA scheduler affinity
* Default to QEMU upstream
 - linux-based qemu stubdom
* Persistent grants for blk (qemu)
* Scalability: 16TiB of RAM
* vTPM updates
* libvirt/libxl integration (external)
* xl USB pass-through for HVM guests using Qemu USB emulation
* xl QXL Spice support
* Rationalized backend scripts

== Features marked as Fair ==

* Scripts for driver domains (depends on backend scripts)

I think this should be a blocker.  Not having driver domains for xl will be a very big regression, and will remove one of the key features that can differentiate us from our competitors.  I think we should consider this one a blocker.
* xl PVUSB pass-through for PV guests
* xl PVUSB pass-through for HVM guests
* NUMA Memory migration
* Multi-page blk rings (external)

== Features at risk ==

* Remove hardcoded mobprobe's in xencommons

As Jan already mentioned,  should be a blocker.  This just needs someone to step up to do it.
* openvswitch toostack integration

I think openvswitch is a win from a benefit/effort point of view.  It's already got an RFC posted by Bastian to the list; and we've got some expertise on openvswitch in the XenServer team -- who can't write it but could maybe give advice / figure out bugs quicker.  If we can just get someone motivated enough to take it up, then we'd have a pretty good feature for not too much work.
* blktap3

One that I really wish we could get into 4.3 is blktap3 -- this is one of the big things keeping "Xen+pvops" from having feature parity with "Xen+classic Xen".  Thanos is doing good work, but only has a few hours a week to dedicate to it.  If someone were able to take it over full-time starting in the next few weeks, it might be possible.  But it's not clear where such a person would come from.
* Xen EFI feature: dom0 able to make use of EFI run-time services

Daniel Kiper is already working on this, but has just started.  The issue (as I understand it) is that if there are systems where the ACPI tables are only discoverable via EFI, then Xen+pvops will not be able to boot if pvops doesn't have EFI run-time support.  The following version of Xen won't come out until probably Q2 2014, and won't hit distros probably until 6 months after that.

Given that, what do we think is the likelihood of such systems cropping up in that timeframe?  If the answer is anything other than "very low", I think that as a strategic measure, this one is probably important enough to slip the schedule a little bit if necessary.

I think everything else is probably fine.

* Guest EFI booting
* Persistent grants for net
* Multi-page net protocol (external)
* V4V: Inter-domain communication
* Wait queues for mm
* xl vm-{export,import}
* PV audio (audio for stubdom qemu)
* IllumOS (OpenSolaris fork) support
* Make storage migration possible
* Full-VM snapshotting
* VM Cloning
* Memory: Replace PoD with paging mechanism

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.