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?
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@lists.xen.org
http://lists.xen.org/xen-devel
> Date: Mon, 16 Apr 2012 12:31:50 +0100 > From: Ian Campbell <Ian.Campbell@citrix.com> > To: xen-devel <xen-devel@lists.xen.org> > Subject: [Xen-devel] 4.2 Release Plan / TODO > Message-ID: <1334575910.14560.146.camel@zakaz.uk.xensource.com> > 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
On Mon, Apr 16, 2012 at 12:31 PM, Ian Campbell <Ian.Campbell@citrix.com> 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 > 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?I''m still hoping to get the PoD patches in, but we''ll see. -George> > 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@lists.xen.org > http://lists.xen.org/xen-devel
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.
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@mariner.uk.xensource.com>. 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@tiscali.it>
* [BUG] does not honour scheduler weight params, reported
by Dieter Bloms in <20120423193518.GA16134@bloms.de>,
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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@mariner.uk.xensource.com>. 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@tiscali.it> > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > 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@eikelenboom.it _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, 2012-04-24 at 14:30 +0100, Sander Eikelenboom wrote:> 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 ?Other than what''s included in this list, I don''t believe there is at the moment.> (both in the sense of commands to xl, as of parsing and building a > domain from the options specified in a domain .cfg)Extracting those things for xl is pretty trivial -- the hard thing is figuring out what options xend has/had, or more importantly which ones of those people actually use (since we clearly aren''t intending to replicate every feature of xend without reference to the utility of or demand for those features). If you can provide a list of xend features which you think are essential (or even just the subset which you are interested in) then I''d be happy to correlate it with xl and add the disjunction to the list.> 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.I''d say there were not "basic" but they certainly aren''t "super advanced" either.> 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 ?I think we will have to handle that on a case by case basis. Some (many?) of them will be trivial and will likely be no-brainers to include at least during the early RCs.> (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 ?We''d have to balance their exoticness against their invasiveness and make a judgement call. Obviously a horribly complex patch for a little used feature will get a different reception to a simple patch for a feature which everyone uses... Ian.
Tuesday, April 24, 2012, 4:30:15 PM, you wrote:> On Tue, 2012-04-24 at 14:30 +0100, Sander Eikelenboom wrote: >> 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 ?> Other than what''s included in this list, I don''t believe there is at the > moment.>> (both in the sense of commands to xl, as of parsing and building a >> domain from the options specified in a domain .cfg)> Extracting those things for xl is pretty trivial -- the hard thing is > figuring out what options xend has/had, or more importantly which ones > of those people actually use (since we clearly aren''t intending to > replicate every feature of xend without reference to the utility of or > demand for those features).> If you can provide a list of xend features which you think are essential > (or even just the subset which you are interested in) then I''d be happy > to correlate it with xl and add the disjunction to the list.I don''t think besides the cpu_weight, assigning/pinning of vcpu''s to domains and pci passthrough i''m using any "special" config options. Mostly using pv-guests though, perhaps there are more options people could be missing on HVM domains. So i think for myself everything is covered, but perhaps something will pop up when i start testing the RC''s.>> 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.> I''d say there were not "basic" but they certainly aren''t "super > advanced" either.That''s why i said "pretty basic", but for pv-guests besides setting domainname, nr of vcpus, memory, disks and kernel/ramdisk, it would be pretty much the next thing someone could want i guess.>> 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 ?> I think we will have to handle that on a case by case basis. Some > (many?) of them will be trivial and will likely be no-brainers to > include at least during the early RCs.Good to know !>> (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 ?> We''d have to balance their exoticness against their invasiveness and > make a judgement call. Obviously a horribly complex patch for a little > used feature will get a different reception to a simple patch for a > feature which everyone uses...> Ian.-- Best regards, Sander mailto:linux@eikelenboom.it
On Wed, 2012-05-02 at 16:02 +0100, Dario Faggioli wrote:> [...] > Therefore, I''m officially proposing to add "automatic NUMA placement and > vcpu pinning in xl" here below: > > > tools, blockers: > > ... > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > > reported by Fabio Fantoni in > > <4F9672DD.2080902@tiscali.it> > > * [BUG] does not honour scheduler weight params, reported > > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > > Dieter has posted a patch. > * does not automatically try to select a (set of) > node(s) on which to create a VM and pin its vcpus > there. > > The strong case I''m making is that not having this is a regression wrt > default xend behaviour, and it could upset and break stuff for people > expecting the toolstack tacking care about NUMA, at least in some rough > way (which btw is what xend is doing). > > I''m not far from having the patches so, if the proposal is accepted, I > can post them next week, I''m quite sure. > > Thoughts?I think this is a reasonable thing to accept for 4.2. BTW, I missed my regular TODO list update this week. Since it is now Wednesday I''m not going to bother this week and will pick up again on Tuesday (Monday is a UK public holiday). Ian.