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

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> Date: Mon, 16 Apr 2012 12:31:50 +0100
> From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> To: xen-devel <xen-devel@xxxxxxxxxxxxx>
> Subject: [Xen-devel] 4.2 Release Plan / TODO
> Message-ID: <1334575910.14560.146.camel@xxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="UTF-8"
>
> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
>
> The time line is as follows:
>
> 19 March        -- TODO list locked down
> 2 April         -- Feature Freeze
>                                                        << WE ARE HERE
> Mid/Late April  -- First release candidate
> Weekly          -- RCN+1 until it is ready
>
> The updated TODO list follows. Per the release plan a strong case will
> now have to be made as to why new items should be added to the list,
> especially as a blocker, rather than deferred to 4.3.
>
> We have now entered Feature Freeze. Patches which have been posted
> before or which address something on the list below are still acceptable
> (for now, we will gradually be getting stricter about this), everything
> else will be deferred until 4.3 by default.
>
> A bunch of new items have been added to the list, mainly due to Ian
> Jacksons review of the libxl API for stability. I believe these are
> mostly under control. Some of these are going to be immediately deferred
> to 4.3 but I have included them in this week's list to allow the
> opportunity for feedback.
>
> Some of the new items are unclaimed. Volunteers would be much
> appreciated.
>
> As discussed last week I have added known bugs to the lists below.
> Please refer me to any should or must be fixed bugs (best way it by
> responding to this mail with a pointer so my threading mailer will track
> it for next week).
>
> hypervisor, blockers:
>       * [BUG] Zombie driver domains.  There's a bug where PV guests with
>         devices passed through with xl hang around as "zombies", with
>         one outstanding page reference.  I think this should really be a
>         blocker. I'm working on this at the moment (George Dunlap).
>               * One of several recent reports of Zombie domains, which
>                 may or may not be all related.
>               * List as hypervisor for now, but may turn out to be a
>                 tools issue.
>
> tools, blockers:
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * Safe fork vs. fd handling hooks. Involves API changes
>                 (Ian J, patches posted)
>               * locking/serialization, e.g., for domain creation. [...]
>                       * Deferred until 4.3. We think this functionality
>                         can be added without impacting API stability.
>               * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>                 Interface needs an overhaul, related to
>                 locking/serialization over domain create (see above).
>                 IanJ to add note about this interface being substandard
>                 but otherwise defer to 4.3.
>               * libxl_{FOO}_exec. Should return a data structure
>                 declaring what to do, not fork and exec themselves.
>                 However we can defer this until 4.3.
>               * libxl_*_path. Majority made internal, only configdir and
>                 lockdir remain public (used by xl). Good enough?
>               * Interfaces which may need to be async:
>                       * libxl_domain_suspend. Nobody has looked at these
>                         at all. A volunteer would be appreciated.
>                       * libxl_domain_create_{new,restore} -- IanJ has
>                         patches as part of event series.
>                       * libxl_domain_{shutdown,reboot}. These are "fast"
>                         functions and there do not need to be async.
>                         (So, DONE with no action required)
>                       * libxl_domain_core_dump. Can take a dummy ao_how
>                         and remain synchronous internally.
>                       * libxl_device_{disk,nic,vkb,add}_add (and
>                         remove?). Roger Pau Monn? fixes disk as part of
>                         hotplug script series and adds infrastructure
>                         which should make the others trivial.
>                       * libxl_cdrom_insert. Should be easy once
>                         disk_{add,remove} done, IanJ to look at.
>                       * libxl_device_disk_local_{attach,detach}. Become
>                         internal as part of Stefano's domain 0 disk
>                         attach series.
>                       * libxl_device_pci_{add,remove}. Less trivial than
>                         the others. A volunteer would be appreciated.
>                       * libxl_xen_console_*. No interface for waiting
>                         and each call just dumps a bit more of the
>                         ring , so is fast. Nothing to do here (therefore
>                         DONE)
>                       * libxl_xen_tmem_*. All functions are "fast" and
>                         therefore no async needed. Exception is
>                         tmem_destroy which Dan Magenheimer says is
>                         obsolete and can just be removed.
>                       * libxl_fork -- IanJ's event series removes all
>                         users of this.
>       * [BUG] Manually ballooning dom0.  xl mem-set 0 [foo] fails with
>         "libxl: error: libxl.c:2569:libxl_set_memory_target: cannot get
>         memory info from /local/domain/0/memory/static-max: No such file
>         or directory". This might be suitable for an enthusiastic
>         on-looker. (George Dunlap, in the absence of said onlooker)
>       * xl compatibility with xm:
>               * None remaining?
>       * 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, patches
>         posted)
>       * file:// backend performance.
>               * qemu-xen-traditional and upstream qemu-xen performance
>                 has been improved and is now satisfactory.
>               * Xen 4.2 will prefer blktap2 if a kernel module is
>                 available (e.g. older dom0 kernel or DKMS provided
>                 kernel module) and will fallback to qemu qdisk if no
>                 blktap2 is available.
>               * There will be no userspace "blktap3" for Xen 4.2
>       * 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)
>
> It seems that none of the above are going to happen for 4.2?

Item 1, no.

Item 2, AMD+paging, people have reported moderate success with what's in
the tree. The AMD folks are looking into trying to reproduce some issues I
run into win7 guest + PV drivers. So it's in, but marked as experimental.

I posted a bunch of hap, shadow and sharing bug fixes that I hope to get
into 4.2. All internal to the hypervisor. Also posted sharing doc patches
for the tools.

Cheers,
Andres

>
> 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. Olaf has let me know that he is probably
>         not going to have time to do this for 4.2, will likely slip to
>         4.3 unless someone else want to pick up that work)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard,
>                 patches sent)
>               * Upstream qemu save restore (Anthony Perard, Stefano
>                 Stabellini, qemu patches applied, waiting for libxl etc
>                 side which has been recently reposted)
>       * 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, waiting on libxl side of qemu upstream save/restore)
>       * xl compatibility with xm:
>               * xl support for autospawning vncviewer (vncviewer=1 or
>                 otherwise) (Goncalo Gomes, waiting on new version of
>                 patches)
>               * support for vif "rate" parameter (Mathieu Gagn?, waiting
>                 on new version of patches)
>               * expose PCI back "permissive" parameter (George Dunlap,
>                 DONE)
>
> [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