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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Hello Ian,

Tuesday, April 24, 2012, 2:53:31 PM, you wrote:

> 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      << SEE BELOW
> Weekly          -- RCN+1 until it is ready

> My initial guesstimate for starting RCs appears to have been somewhat
> optimistic. I think we need to have reduced at least the blockers lists
> rather significantly before we start thinking of doing RCs.

Is there any list/overview as to the state of feature parity between xm/xend 
and xl/libxl ?
(both in the sense of commands to xl, as of parsing and building a domain from 
the options specified in a domain .cfg)

This week i noticed that someone else noticed that cpu_weight & co .cfg options 
where missing support and provided patches, but these seem like pretty basic 
config options.
This raises the question if there are more pretty basic options still missing 
and in what way will they be handled during the RC's ?
(since there is a good chance more will pop up when more users start testing)

Are patches for not to exotic and/or invasive options still acceptable ?
Or will they have to wait for a 4.2.1 which could follow up pretty short then ?

(probably hard to give a hard rule of thumb, but perhaps something to do a 
little thinking about what could happen)



> A fairly large proportion of the list has been posted at least once, and
> much of it seems ready (or almost ready) to go in. There are however
> still some smaller items which are unclaimed. Based on feedback from
> those who are working on the bigger outstanding items it seems like most
> of them ought to be ready to land in the next few weeks.

> On that basis I think doing a first release candidate in Mid/Late May is
> more realistic. I'll reflect that in next weeks update

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

> 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.
>         Fixed (DONE, Tim Deegan)
>       * Performance regression due to contention on p2m lock. (Tim,
>         Andres)
>  
> 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)
>               * libxl_wait_for_free_memory/libxl_wait_for_memory_target.
>                 Interface needs an overhaul, related to
>                 locking/serialization over domain create (deferred to
>                 4.3). 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 (therefore DONE with
>                 no work).
>               * 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. Probably need to move
>                         xc_domain_save into a separate process, as per
>                         <20366.40183.410388.447630@xxxxxxxxxxxxxxxxxxxxxxxx>. 
> Likely need to do the same for xc_domain_restore too. I'm not sure if IanJ is 
> working (or planning to work on) this.
>                       * libxl_domain_create_{new,restore} -- IanJ has
>                         patches as part of event series.
>                       * libxl_domain_core_dump. Can take a dummy ao_how
>                         and remain synchronous internally. (IanC, patch
>                         posted)
>                       * 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. (Roger
>                         investigating)
>                       * libxl_cdrom_insert. Should be easy once
>                         disk_{add,remove} done, IanJ to look at (or
>                         doing so?).
>                       * libxl_device_disk_local_{attach,detach}. Become
>                         internal as part of Stefano's domain 0 disk
>                         attach series (patches posted)
>                       * libxl_device_pci_{add,remove}. Roger
>                         investigating along with other add,remove
>                         functions.
>                       * 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. (Ian C, patch
>                         posted to remove tmem_destroy)
>                       * libxl_fork -- IanJ's event series will remove
>                         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:
>               * [BUG] cannot create an empty CD-ROM driver on HVM guest,
>                 reported by Fabio Fantoni in
>                 <4F9672DD.2080902@xxxxxxxxxx>
>               * [BUG] does not honour scheduler weight params, reported
>                 by Dieter Bloms in <20120423193518.GA16134@xxxxxxxx>,
>                 Dieter has posted a patch.
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
>               * xl to refuse to run if xend is runnig, Roger Pau MonnÃ
>                 (patch posted)
>       * 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."
>               * Deferred until 4.3
>       * Sharing support for AMD (Tim, Andres), in, marked as
>         experimental (so, DONE, as far as 4.2 is concerned).
>       * PoD performance improvements (George Dunlap)

> 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)
>               * Will defer until 4.3.
>       * 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)
>         DONE, at least as far as 4.2 is concerned.
>       * 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Ã, first
>                 part applied)

> [0] http://lists.xen.org/archives/html/xen-devel/2012-03/msg00883.html






-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel