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 May -- 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.
hypervisor, blockers:
* Performance regression due to contention on p2m lock. Patches
posted, reviewed, updated, to go in shortly (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_*_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
to remove tmem_destroy included, DONE)
* 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's patch has been accepted. (DONE, However see
next bug...)
* [BUG] Spurious CPU params error message when starting a
domain, e.g. "Cpu weight out of range, valid values are
within range from 1 to 65535". This is an issue with
Dieter Bloms' patch to honour scheduler params.
* does not automatically try to select a (set of) node(s)
on which to create a VM and pin its vcpus there. (Dario
Faggioli)
* 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 running, 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 (DONE)
* qemu-xen-traditional and upstream qemu-xen performance
has been improved and is now satisfactory. (Hence this
whole item is DONE)
* 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:
* PoD performance improvements (George Dunlap)
tools, nice to have:
* 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)
* 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, new version of patch posted
recently)
* support for vif "rate" parameter (Mathieu Gagné, all
now
applied, 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
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:> * [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)I just tried this and it appeared to work, has it been sneakily fixed?
On 08/05/12 11:32, Ian Campbell wrote:> On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: >> * [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) > I just tried this and it appeared to work, has it been sneakily fixed?Seems to work for me too -- I do vaguely recall someone (perhaps Goncalo?) volunteering to fix it. At any rate, I''m happy taking it off the list. Thanks for checking. -George
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell 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 May -- First release candidate > Weekly -- RCN+1 until it is readyI think the critical path here is the libxl stable API stuff. Of these I think the elements are IanJ's series to handle fork etc and various other bits, followed by Roger's hotplug stuff (which depends on IanJ's stuff). I'm bit unsure which bits of the following list are done, in-progress (part of a posted or unposted series) or yet to be started. Could you guys have a quick look through and let me know? Also, is it worth trying to find some other heads to take over some of the smaller side, non-dependent issues to clear your path (IanJ in particular)?> 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_*_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 > to remove tmem_destroy included, DONE) > * libxl_fork -- IanJ's event series will remove > all users of this._______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, 2012-05-08 at 11:39 +0100, George Dunlap wrote:> On 08/05/12 11:32, Ian Campbell wrote: > > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > >> * [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) > > I just tried this and it appeared to work, has it been sneakily fixed? > Seems to work for me too -- I do vaguely recall someone (perhaps > Goncalo?) volunteering to fix it. At any rate, I''m happy taking it off > the list. Thanks for checking.Great, I''ll mark it DONE next week. Ian.
Ian Campbell
2012-May-08 10:45 UTC
sched params spurious error message (Was: Re: 4.2 TODO / Release Status)
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:> * xl compatibility with xm: > [...] > * [BUG] does not honour scheduler weight params, reported > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > Dieter''s patch has been accepted. (DONE, However see > next bug...) > * [BUG] Spurious CPU params error message when starting a > domain, e.g. "Cpu weight out of range, valid values are > within range from 1 to 65535". This is an issue with > Dieter Bloms'' patch to honour scheduler params.Is anyone looking into this? Ian.
Ian Campbell
2012-May-08 10:47 UTC
Volunteer wanted: xl and empty HVM CD ROM drives (Was: Re: 4.2 TODO / Release Status)
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:> [...] * xl compatibility with xm: > * [BUG] cannot create an empty CD-ROM driver on HVM guest, > reported by Fabio Fantoni in > <4F9672DD.2080902@tiscali.it>I don''t think anyone is currently working on this. Any volunteers? I think this should be a relatively easy thing, suitable for a beginner (e..g someone who is interested in making a start at toolstack hacking.) Ian.
Ian Campbell
2012-May-08 10:52 UTC
Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
Where are we with the following?
I've not seen anything recently about PCI passthrough.
Is it still the case that save/restore is waiting on lib{c,l} patches
and Remus is waiting for those? What's the hold up there?
On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote:> tools, nice to have:
> * 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)
> * 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, new version of patch posted
> recently)
> * support for vif "rate" parameter (Mathieu Gagné,
all now
> applied, 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Dieter Bloms
2012-May-08 10:56 UTC
Re: sched params spurious error message (Was: Re: 4.2 TODO / Release Status)
Hi, On Tue, May 08, Ian Campbell wrote:> On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: > > * xl compatibility with xm: > > [...] > > * [BUG] does not honour scheduler weight params, reported > > by Dieter Bloms in <20120423193518.GA16134@bloms.de>, > > Dieter''s patch has been accepted. (DONE, However see > > next bug...) > > * [BUG] Spurious CPU params error message when starting a > > domain, e.g. "Cpu weight out of range, valid values are > > within range from 1 to 65535". This is an issue with > > Dieter Bloms'' patch to honour scheduler params. > > Is anyone looking into this?I''ve made a little patch to set this value to 256 when it wasn''t defined in the configfile, but George Dunlap didn''t like it (rightly). I''m sorry, my skill is not enough to implement a reasonable solution for this issue :( Maybe we should revert my patch as long as there isn''t a fix. -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won''t use my address in the From field.
George Dunlap
2012-May-08 12:35 UTC
Re: sched params spurious error message (Was: Re: 4.2 TODO / Release Status)
On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms <dieter@bloms.de> wrote:>> > * [BUG] Spurious CPU params error message when starting a >> > domain, e.g. "Cpu weight out of range, valid values are >> > within range from 1 to 65535". This is an issue with >> > Dieter Bloms'' patch to honour scheduler params. >> >> Is anyone looking into this? > > I''ve made a little patch to set this value to 256 when it wasn''t defined > in the configfile, but George Dunlap didn''t like it (rightly). > I''m sorry, my skill is not enough to implement a reasonable solution for > this issue :( > Maybe we should revert my patch as long as there isn''t a fix.No, I think having the ability to set it is important. You can mark this "George will do it if no one else steps up". :-) Thanks for your help, Dieter. -George
Shriram Rajagopalan
2012-May-08 12:45 UTC
Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
On 2012-05-08, at 5:52 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> Where are we with the following? > > I've not seen anything recently about PCI passthrough. > > Is it still the case that save/restore is waiting on lib{c,l} patches > and Remus is waiting for those? What's the hold up there?The last I remember, Stefano reposted the patches for the Nth time but unfortunately forgot to add the acked-by from someone. I stopped reposting my patches every time Stefano reposted his, lest I spam the list. I am just waiting for his patches to go in before I rebase/repost mine. Shriram> > On Tue, 2012-05-08 at 10:34 +0100, Ian Campbell wrote: >> tools, nice to have: >> * 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) >> * 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, new version of patch posted >> recently) >> * support for vif "rate" parameter (Mathieu Gagné, all now >> applied, 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 > > > > _______________________________________________ > 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
Ian Campbell
2012-May-08 12:50 UTC
Re: sched params spurious error message (Was: Re: 4.2 TODO / Release Status)
On Tue, 2012-05-08 at 13:35 +0100, George Dunlap wrote:> On Tue, May 8, 2012 at 11:56 AM, Dieter Bloms <dieter@bloms.de> wrote: > >> > * [BUG] Spurious CPU params error message when starting a > >> > domain, e.g. "Cpu weight out of range, valid values are > >> > within range from 1 to 65535". This is an issue with > >> > Dieter Bloms'' patch to honour scheduler params. > >> > >> Is anyone looking into this? > > > > I''ve made a little patch to set this value to 256 when it wasn''t defined > > in the configfile, but George Dunlap didn''t like it (rightly). > > I''m sorry, my skill is not enough to implement a reasonable solution for > > this issue :( > > Maybe we should revert my patch as long as there isn''t a fix. > > No, I think having the ability to set it is important. You can mark > this "George will do it if no one else steps up". :-)You''ve got yerself a deal ;-)> Thanks for your help, Dieter.Yes, thanks! Ian.
On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote:> 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.For the beginning, I have the following points: * xs.h -> xenstore.h * Directory usage in libxl - dumps in /var/xen: wtf? - user data files in /var/lib/xen: What are the guarantees given for this files? - /var/run/libxl for temporary files Bastian -- Deflector shields just came on, Captain.
On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote:> On Tue, May 08, 2012 at 10:34:15AM +0100, Ian Campbell wrote: > > 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. > > For the beginning, I have the following points: > > * xs.h -> xenstore.hI think there was general agreement that this should be done for 4.2.> * Directory usage in libxl > - dumps in /var/xen: wtf?This is the same location as xend uses, so in that sense it is compatible. However I don''t think this is somewhere that xl (nb: this is a property of xl, not libxl) needs to slavishly follow what xend did. What would the correct FHS location for these dumps be?> - user data files in /var/lib/xen: > What are the guarantees given for this files?I suppose you are asking for /var/lib vs /var/run (or /run) reasons? One of the keys by which you lookup this userdata is domid. Which means that the lifetime of this data is bounded by the life of a domain. Which means that it need not persist over reboot (which I think argues for (/var)?/run) I suppose the other interesting facet is allowable size. The description of the interface doesn''t have anything to say about size. Ian J -- any thoughts?> - /var/run/libxl for temporary filesAre you suggesting that this is being wrongly used by libxl, or that libxl should use this location for more things than it currently does? Perhaps some stuff should instead be in /tmp or $TMPDIR? Other than the xs.h naming issue I don''t see anything here which I think is a blocker for 4.2, I''d say they are mostly "nice to have". Ian.
Stefano Stabellini
2012-May-08 14:54 UTC
Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
On Tue, 8 May 2012, Ian Campbell wrote:> Where are we with the following? > > I''ve not seen anything recently about PCI passthrough.The last patch series that was sent is: http://marc.info/?l=qemu-devel&m=133346733411606&w=2 it is still stuck waiting for reviews. Given that QEMU is in freeze for the next release release now, I don''t think anything is going to happen in the next few weeks. I could backport the patch series to the upstream QEMU tree that we use with xen-unstable, but considering that we are in freeze ourselves and that upstream QEMU is not used by default with HVM guests we might as well wait for the beginning of the next release cycle.> Is it still the case that save/restore is waiting on lib{c,l} patches > and Remus is waiting for those? What''s the hold up there?The libxl save/restore patches haven''t been applied yet.
Ian Campbell
2012-May-08 14:59 UTC
Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote:> On Tue, 8 May 2012, Ian Campbell wrote: > > Where are we with the following? > > > > I''ve not seen anything recently about PCI passthrough. > > The last patch series that was sent is: > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > it is still stuck waiting for reviews. Given that QEMU is in freeze for > the next release release now, I don''t think anything is going to happen > in the next few weeks. > I could backport the patch series to the upstream QEMU tree that we use > with xen-unstable, but considering that we are in freeze ourselves and > that upstream QEMU is not used by default with HVM guests we > might as well wait for the beginning of the next release cycle.Thanks. I will mark these as "deferred to 4.3" and remove from the list. If they do go into upstream we can revisit whether we backport.> > Is it still the case that save/restore is waiting on lib{c,l} patches > > and Remus is waiting for those? What''s the hold up there? > > The libxl save/restore patches haven''t been applied yet.Ian J -- have you dropped these or are you waiting for something? Ian.
Shriram Rajagopalan
2012-May-08 15:06 UTC
Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
On Tue, May 8, 2012 at 9:59 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > > On Tue, 8 May 2012, Ian Campbell wrote: > > > Where are we with the following? > > > > > > I''ve not seen anything recently about PCI passthrough. > > > > The last patch series that was sent is: > > > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > > > it is still stuck waiting for reviews. Given that QEMU is in freeze for > > the next release release now, I don''t think anything is going to happen > > in the next few weeks. > > I could backport the patch series to the upstream QEMU tree that we use > > with xen-unstable, but considering that we are in freeze ourselves and > > that upstream QEMU is not used by default with HVM guests we > > might as well wait for the beginning of the next release cycle. > > Thanks. I will mark these as "deferred to 4.3" and remove from the list. > If they do go into upstream we can revisit whether we backport. > > > > Is it still the case that save/restore is waiting on lib{c,l} patches > > > and Remus is waiting for those? What''s the hold up there? > > > > The libxl save/restore patches haven''t been applied yet. > > Ian J -- have you dropped these or are you waiting for something? > > >Ian J, also note that the remus libxl patches may not apply cleanly after applying stefano''s patches (even these might require some re-basing), given that a lot of patches that came in later (the event based stuff, Ian C''s refactorings,etc) went in. If you could just let me know when they have been committed, I can certainly rebase mine and post them. thanks shriram _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote:> On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > > * Directory usage in libxl > > - dumps in /var/xen: wtf? > However I don''t think this is somewhere that xl (nb: this is a property > of xl, not libxl) needs to slavishly follow what xend did. > What would the correct FHS location for these dumps be?Unsure. The FHS defines /var/crash for system crash dumps, but it is not used everywhere. So I would use /var/lib/xen/dump or so.> > - user data files in /var/lib/xen: > > What are the guarantees given for this files? > I suppose you are asking for /var/lib vs /var/run (or /run) reasons?Exactly.> One of the keys by which you lookup this userdata is domid. Which means > that the lifetime of this data is bounded by the life of a domain. Which > means that it need not persist over reboot (which I think argues for > (/var)?/run)I don''t think rebooting the control domain without rebooting Xen will work right now. So /var/run is the correct location. On further thoughts: Why not push them into xenstore?> > - /var/run/libxl for temporary files > Are you suggesting that this is being wrongly used by libxl, or that > libxl should use this location for more things than it currently does? > Perhaps some stuff should instead be in /tmp or $TMPDIR?$TMPDIR or the fallback /tmp is the correct location.> Other than the xs.h naming issue I don''t see anything here which I think > is a blocker for 4.2, I''d say they are mostly "nice to have".I''m just collecting changes for the Debian packages. Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
On Tue, May 08, Ian Campbell 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 May -- 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.Please consider "tools/configure: add options to pass EXTRA_CFLAGS" http://lists.xen.org/archives/html/xen-devel/2012-04/msg00537.html Since qemu-upstream was imported, building tools with RPM_OPT_FLAGS will not work anymore. Olaf
On Tue, 2012-05-08 at 11:11 -0400, Bastian Blank wrote:> On Tue, May 08, 2012 at 03:38:53PM +0100, Ian Campbell wrote: > > On Tue, 2012-05-08 at 10:09 -0400, Bastian Blank wrote: > > > * Directory usage in libxl > > > - dumps in /var/xen: wtf? > > However I don''t think this is somewhere that xl (nb: this is a property > > of xl, not libxl) needs to slavishly follow what xend did. > > What would the correct FHS location for these dumps be? > > Unsure. The FHS defines /var/crash for system crash dumps, but it is not > used everywhere. So I would use /var/lib/xen/dump or so.OK. Do you have that patch to hand?> > > - user data files in /var/lib/xen: > > > What are the guarantees given for this files? > > I suppose you are asking for /var/lib vs /var/run (or /run) reasons? > > Exactly.Do you have that patch to hand too?> > One of the keys by which you lookup this userdata is domid. Which means > > that the lifetime of this data is bounded by the life of a domain. Which > > means that it need not persist over reboot (which I think argues for > > (/var)?/run) > > I don''t think rebooting the control domain without rebooting Xen will > work right now. So /var/run is the correct location.Right. (Can you guess my next question...) Do you have that patch to hand too? ( ;-) )> On further thoughts: Why not push them into xenstore?AIUI the userdata facility is provided specifically for data which is unsuitable for xenstore, due to size or whatever (XS has various limits, to avoid abuse, which are relatively low).> > > - /var/run/libxl for temporary files > > Are you suggesting that this is being wrongly used by libxl, or that > > libxl should use this location for more things than it currently does? > > Perhaps some stuff should instead be in /tmp or $TMPDIR? > > $TMPDIR or the fallback /tmp is the correct location. > > > Other than the xs.h naming issue I don''t see anything here which I think > > is a blocker for 4.2, I''d say they are mostly "nice to have". > > I''m just collecting changes for the Debian packages.Sure. I guess you will send out those patches as and when you are happy with them? Cheers, Ian.
Ian Jackson
2012-May-09 13:42 UTC
Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
Shriram Rajagopalan writes ("Re: Upstream Qemu Status (Was: Re: [Xen-devel]
4.2 TODO / Release Status)"):> On Tue, May 8, 2012 at 9:59 AM, Ian Campbell
<Ian.Campbell@citrix.com<mailto:Ian.Campbell@citrix.com>> wrote:
> > The libxl save/restore patches haven''t been applied yet.
>
> Ian J -- have you dropped these or are you waiting for something?
I have an enormous patch backlog. Apologies to everyone. We have
been dealing with an unrelated crisis here.
Ian.
Ian Campbell
2012-May-10 10:18 UTC
Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status))
On Wed, 2012-05-09 at 14:42 +0100, Ian Jackson wrote:> I have an enormous patch backlog. Apologies to everyone.I think it would be useful to have another committer to help keep the turnaround time for libxl patches (one of our most actively developed components) down. I''ve been reviewing many of the patches anyway so how about I volunteer for that role. I''m not actually a libxl MAINTAINER so I suppose I should also nominate myself for that too. We don''t seem to have a separate libxl entry in MAINTAINERS, just the top level "tools". We could split it out explicitly (which I think might be a good idea anyway) or just go with: 8<---------------------------------------------------- MAINTAINERS: add myself as a tools maintainer Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 8aba3396a61a MAINTAINERS --- a/MAINTAINERS Tue May 08 15:00:12 2012 +0100 +++ b/MAINTAINERS Thu May 10 11:11:10 2012 +0100 @@ -217,6 +217,7 @@ F: stubdom/ TOOLSTACK M: Ian Jackson <ian.jackson@eu.citrix.com> M: Stefano Stabellini <stefano.stabellini@eu.citrix.com> +M: Ian Campbell <ian.campbell@citrix.com> S: Supported F: tools/ Ian.
Stefano Stabellini
2012-May-10 10:46 UTC
Re: Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status))
On Thu, 10 May 2012, Ian Campbell wrote:> On Wed, 2012-05-09 at 14:42 +0100, Ian Jackson wrote: > > I have an enormous patch backlog. Apologies to everyone. > > I think it would be useful to have another committer to help keep the > turnaround time for libxl patches (one of our most actively developed > components) down. > > I''ve been reviewing many of the patches anyway so how about I volunteer > for that role. > > I''m not actually a libxl MAINTAINER so I suppose I should also nominate > myself for that too. We don''t seem to have a separate libxl entry in > MAINTAINERS, just the top level "tools". We could split it out > explicitly (which I think might be a good idea anyway) or just go with: > > 8<---------------------------------------------------- > > MAINTAINERS: add myself as a tools maintainer > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > > diff -r 8aba3396a61a MAINTAINERS > --- a/MAINTAINERS Tue May 08 15:00:12 2012 +0100 > +++ b/MAINTAINERS Thu May 10 11:11:10 2012 +0100 > @@ -217,6 +217,7 @@ F: stubdom/ > TOOLSTACK > M: Ian Jackson <ian.jackson@eu.citrix.com> > M: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > +M: Ian Campbell <ian.campbell@citrix.com> > S: Supported > F: tools/ >Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Ian Jackson
2012-May-10 11:20 UTC
Extra libxl committer? (Was: Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status))
Ian Campbell writes ("[Xen-devel] Extra libxl committer? (Was: Re: Upstream
Qemu Status (Was: Re: 4.2 TODO / Release
Status))"):> MAINTAINERS: add myself as a tools maintainer
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell
2012-May-14 08:56 UTC
Re: Upstream Qemu Status (Was: Re: 4.2 TODO / Release Status)
On Tue, 2012-05-08 at 16:06 +0100, Shriram Rajagopalan wrote:> On Tue, May 8, 2012 at 9:59 AM, Ian Campbell <Ian.Campbell@citrix.com> > wrote: > On Tue, 2012-05-08 at 10:54 -0400, Stefano Stabellini wrote: > > On Tue, 8 May 2012, Ian Campbell wrote: > > > Where are we with the following? > > > > > > I''ve not seen anything recently about PCI passthrough. > > > > The last patch series that was sent is: > > > > http://marc.info/?l=qemu-devel&m=133346733411606&w=2 > > > > it is still stuck waiting for reviews. Given that QEMU is in > freeze for > > the next release release now, I don''t think anything is > going to happen > > in the next few weeks. > > I could backport the patch series to the upstream QEMU tree > that we use > > with xen-unstable, but considering that we are in freeze > ourselves and > > that upstream QEMU is not used by default with HVM guests we > > might as well wait for the beginning of the next release > cycle. > > > Thanks. I will mark these as "deferred to 4.3" and remove from > the list. > If they do go into upstream we can revisit whether we > backport. > > > > Is it still the case that save/restore is waiting on > lib{c,l} patches > > > and Remus is waiting for those? What''s the hold up there? > > > > The libxl save/restore patches haven''t been applied yet. > > > > Ian J -- have you dropped these or are you waiting for > something? > > > > > > Ian J, also note that the remus libxl patches may not apply cleanly > after > applying stefano''s patches (even these might require some re-basing), > given that a lot of patches that came in later (the event based stuff, > Ian C''s refactorings,etc) > went in. > > If you could just let me know when they have been committed, I can > certainly rebase mine and post them.Seems like this request was missed -- the libxl save patches seem to be in now, please do rebase+repost. Ian.