Xen project Mailing List

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.

-George

* 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

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