Day late due to doc day yesterday. FYI I'll be at the hackathon next
week so I expect I'll be skipping that update.
As usual please ping me with any updates/corrections.
hypervisor, blockers:
* domctls / sysctls set up to modify scheduler parameters, like
the credit1 timeslice and schedule rate. (George Dunlap, patches
posted)
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:
* add libxl_defbool and generally try and arrange that
memset(foo,0,...) requests the defaults (Ian Campbell,
patches reposted)
* Safe fork vs. fd handling hooks. This is an API
addition, so maybe not required fro stable API, bit need
to have for 4.2? (Ian J, patches posted)
* xl feature parity with xend wrt driver domain support
(George Dunlap)
* More formally deprecate xm/xend. Manpage patches already
in tree. Needs release noting and communication around
-rc1 to remind people to test xl.
* Correct paging/sharing tools buffer mlocking (Tim, Andres,
patches posted)
* Autoconf (Roger Pau Monné & Ian J, DONE)
* xl support for "rtc_timeoffset" and "localtime"
(Nobody AFAICT)
hypervisor, nice to have:
*
* solid implementation of sharing/paging/mem-events (using work
queues) (Tim Deegan, Olaf Herring et al)
* A long standing issue is a fully synchronized p2m (locking
lookups) (Andres Lagar-Cavilla, DONE)
tools, nice to have:
* Hotplug script stuff -- internal to libxl (I think, therefore I
didn't put this under stable API above) but still good to have
for 4.2? (Roger Pau Monné, patches posted)
* Block script support -- follows on from hotplug script (Roger
Pau Monné)
* Configure/control paging via xl/libxl (Olaf Herring)
* Upstream qemu feature patches:
* Upstream qemu PCI passthrough support (Anthony Perard,
patches sent)
* Upstream qemu save restore (Anthony Perard, Stefano
Stabellini, patches sent, waiting for upstream ack)
* Nested-virtualisation (currently should be marked experimental,
likely to release that way? Consider nested-svm separate to
nested-vmx. Nested-svm is in better shape)
* Initial xl support for Remus (memory checkpoint, blackholing)
(Shriram, patches posted, blocked behind qemu save restore
patches)
* xl support for autospawning vncviewer (vncviewer=1 or otherwise)
(Nobody AFAICT)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Tue, Feb 28, 2012 at 12:50 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> Day late due to doc day yesterday. FYI I''ll be at the hackathon next > week so I expect I''ll be skipping that update. > > As usual please ping me with any updates/corrections. > > hypervisor, blockers: > * domctls / sysctls set up to modify scheduler parameters, like > the credit1 timeslice and schedule rate. (George Dunlap, patches > posted)Hypervisor patches and (I believe) libxc patches committed; just libxl / xl patches outstanding.> 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: > * add libxl_defbool and generally try and arrange that > memset(foo,0,...) requests the defaults (Ian Campbell, > patches reposted) > * Safe fork vs. fd handling hooks. This is an API > addition, so maybe not required fro stable API, bit need > to have for 4.2? (Ian J, patches posted) > * xl feature parity with xend wrt driver domain support > (George Dunlap) > * More formally deprecate xm/xend. Manpage patches already > in tree. Needs release noting and communication around > -rc1 to remind people to test xl. > * Correct paging/sharing tools buffer mlocking (Tim, Andres, > patches posted) > * Autoconf (Roger Pau Monné & Ian J, DONE) > * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT) > > hypervisor, nice to have: > * > * solid implementation of sharing/paging/mem-events (using work > queues) (Tim Deegan, Olaf Herring et al) > * A long standing issue is a fully synchronized p2m (locking > lookups) (Andres Lagar-Cavilla, DONE) > > tools, nice to have: > > * Hotplug script stuff -- internal to libxl (I think, therefore I > didn''t put this under stable API above) but still good to have > for 4.2? (Roger Pau Monné, patches posted) > * Block script support -- follows on from hotplug script (Roger > Pau Monné) > * Configure/control paging via xl/libxl (Olaf Herring) > * Upstream qemu feature patches: > * Upstream qemu PCI passthrough support (Anthony Perard, > patches sent) > * Upstream qemu save restore (Anthony Perard, Stefano > Stabellini, patches sent, waiting for upstream ack) > * Nested-virtualisation (currently should be marked experimental, > likely to release that way? Consider nested-svm separate to > nested-vmx. Nested-svm is in better shape) > * Initial xl support for Remus (memory checkpoint, blackholing) > (Shriram, patches posted, blocked behind qemu save restore > patches) > * xl support for autospawning vncviewer (vncviewer=1 or otherwise) > (Nobody AFAICT) > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
2012/2/28 Ian Campbell <Ian.Campbell@citrix.com>:> Day late due to doc day yesterday. FYI I'll be at the hackathon next > week so I expect I'll be skipping that update. > > As usual please ping me with any updates/corrections. > > hypervisor, blockers: > * domctls / sysctls set up to modify scheduler parameters, like > the credit1 timeslice and schedule rate. (George Dunlap, patches > posted) > > 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: > * add libxl_defbool and generally try and arrange that > memset(foo,0,...) requests the defaults (Ian Campbell, > patches reposted) > * Safe fork vs. fd handling hooks. This is an API > addition, so maybe not required fro stable API, bit need > to have for 4.2? (Ian J, patches posted) > * xl feature parity with xend wrt driver domain support > (George Dunlap) > * More formally deprecate xm/xend. Manpage patches already > in tree. Needs release noting and communication around > -rc1 to remind people to test xl. > * Correct paging/sharing tools buffer mlocking (Tim, Andres, > patches posted) > * Autoconf (Roger Pau Monné & Ian J, DONE) > * xl support for "rtc_timeoffset" and "localtime" (Nobody AFAICT)* yajl 2.0 support is still not finished I think, Olaf patches have not yet been committed to the repository, this should be a blocker.> > hypervisor, nice to have: > * > * solid implementation of sharing/paging/mem-events (using work > queues) (Tim Deegan, Olaf Herring et al) > * A long standing issue is a fully synchronized p2m (locking > lookups) (Andres Lagar-Cavilla, DONE) > > tools, nice to have: > > * Hotplug script stuff -- internal to libxl (I think, therefore I > didn't put this under stable API above) but still good to have > for 4.2? (Roger Pau Monné, patches posted) > * Block script support -- follows on from hotplug script (Roger > Pau Monné) > * Configure/control paging via xl/libxl (Olaf Herring) > * Upstream qemu feature patches: > * Upstream qemu PCI passthrough support (Anthony Perard, > patches sent) > * Upstream qemu save restore (Anthony Perard, Stefano > Stabellini, patches sent, waiting for upstream ack) > * Nested-virtualisation (currently should be marked experimental, > likely to release that way? Consider nested-svm separate to > nested-vmx. Nested-svm is in better shape) > * Initial xl support for Remus (memory checkpoint, blackholing) > (Shriram, patches posted, blocked behind qemu save restore > patches) > * xl support for autospawning vncviewer (vncviewer=1 or otherwise) > (Nobody AFAICT) > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Hi, On 2/28/12 7:50 AM, Ian Campbell wrote:> 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: > * More formally deprecate xm/xend. Manpage patches already > in tree. Needs release noting and communication around > -rc1 to remind people to test xl.Will there be support for rate limiting for vif as there is in xm/xend? The help for the command "network-attach" shows support for "rate". Unfortunately, an error occurs when using the "rate" parameter: "the rate parameter for vifs is currently not supported" The same applies for the "accel" parameter which I don''t know the purpose and don''t use. -- Mathieu
On Tue, 2012-02-28 at 15:08 +0000, Mathieu Gagné wrote:> Hi, > > On 2/28/12 7:50 AM, Ian Campbell wrote: > > 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: > > * More formally deprecate xm/xend. Manpage patches already > > in tree. Needs release noting and communication around > > -rc1 to remind people to test xl. > > Will there be support for rate limiting for vif as there is in xm/xend? > > The help for the command "network-attach" shows support for "rate". > Unfortunately, an error occurs when using the "rate" parameter: > "the rate parameter for vifs is currently not supported"I think this ought to be fixed before 4.2. It should be a fairly simple matter to plumb the parameter through to the underlying xenstore key. If you feel up to creating a patch I'd be happy to give some guidance.> The same applies for the "accel" parameter which I don't know the > purpose and don't use.This enables (or would, if it were implemented) the use of the old h/w acceleration interface for netchannel. I'm not sure if anyone is still using or supporting this either. I don't think there is any support in the upstream kernels for this stuff either. I'm inclined to omit it for 4.2 unless someone is keen to do the necessary work. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Roger Pau Monné wrote> > * yajl 2.0 support is still not finished I think, Olaf patches > have not yet been committed to the repository, this should be a > blocker. >Yes, without such patches the build on Wheezy fails. -- View this message in context: http://xen.1045712.n5.nabble.com/4-2-TODO-List-tp5521733p5522191.html Sent from the Xen - Dev mailing list archive at Nabble.com. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 2/28/12 10:21 AM, Ian Campbell wrote:> On Tue, 2012-02-28 at 15:08 +0000, Mathieu Gagné wrote: >> >> Will there be support for rate limiting for vif as there is in xm/xend? >> >> The help for the command "network-attach" shows support for "rate". >> Unfortunately, an error occurs when using the "rate" parameter: >> "the rate parameter for vifs is currently not supported" > > I think this ought to be fixed before 4.2. > > It should be a fairly simple matter to plumb the parameter through to > the underlying xenstore key. If you feel up to creating a patch I'd be > happy to give some guidance. >Someone already proposed [1] a patch which accept rate in the form "kb_per_sec,timeslice_usec". However it got rejected [1] because xm/xend accepts this syntax (1Mb/s@1ms) instead and backward compatibility should be preserved. What should be the syntax for this parameter? [1] http://lists.xen.org/archives/html/xen-devel/2011-03/msg01963.html [2] http://lists.xen.org/archives/html/xen-devel/2011-03/msg01978.html -- Mathieu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, 2012-02-28 at 15:47 +0000, Mathieu Gagné wrote:> On 2/28/12 10:21 AM, Ian Campbell wrote: > > On Tue, 2012-02-28 at 15:08 +0000, Mathieu Gagné wrote: > >> > >> Will there be support for rate limiting for vif as there is in xm/xend? > >> > >> The help for the command "network-attach" shows support for "rate". > >> Unfortunately, an error occurs when using the "rate" parameter: > >> "the rate parameter for vifs is currently not supported" > > > > I think this ought to be fixed before 4.2. > > > > It should be a fairly simple matter to plumb the parameter through to > > the underlying xenstore key. If you feel up to creating a patch I'd be > > happy to give some guidance. > > > > Someone already proposed [1] a patch which accept rate in the form > "kb_per_sec,timeslice_usec". However it got rejected [1] because xm/xend > accepts this syntax (1Mb/s@1ms) instead and backward compatibility > should be preserved. > > What should be the syntax for this parameter?It should be the xend syntax unless whoever implements itcan make a convincing argument why some other syntax is "better enough" to justify breaking backwards conmpat.> > [1] http://lists.xen.org/archives/html/xen-devel/2011-03/msg01963.html > [2] http://lists.xen.org/archives/html/xen-devel/2011-03/msg01978.html >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, 2012-02-28 at 14:56 +0000, Roger Pau Monné wrote:> * yajl 2.0 support is still not finished I think, Olaf patches > have not yet been committed to the repository, this should be a > blocker.I think these have gone in in the meantime so I won't include that in this weeks TODO -- please correct me if this is not right. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel