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.
A lot of new DONE and one of the bigger items (IanJ's async
bootloader/create/fork series) is now in. The remaining big items are
the hotplug script series and asynchronisation of migration.
We have made a freeze exception for George's "pciback autobind"
patch to
xl, since it is self contained. Likewise Bastian's suggestion to rename
xs.h -> xenstore.h (since the old name is too short and now conflicts
with another project) has been accepted (with compat symlinks) for 4.2
in order to get the transition under way ASAP.
Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.
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, I think this was actually DONE a while back and
I missed it)
* 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. (IanJ).
* libxl_domain_create_{new,restore} -- IanJ has
patches as part of event series, (DONE).
* libxl_domain_core_dump. Can take a dummy ao_how
and remain synchronous internally. (IanC, DONE)
* libxl_device_{disk,nic,vkb,add,pci}_add (and
remove?). Roger Pau Monné fixes disk as part of
hotplug script series and adds infrastructure
which should make the others trivial. (Roger,
WIP)
* 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, another round
required?)
* libxl_fork -- IanJ's event series will remove
all users of this. (DONE)
* [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. (Seems to have been fixed, DONE)
* 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] 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". ("George will do it if
no
one else steps up")
* does not automatically try to select a (set of) node(s)
on which to create a VM and pin its vcpus there. (Dario
Faggioli, patches posted)
* 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, needs rebase)
* Domain 0 block attach & general hotplug when using qdisk backend
(need to start qemu as necessary etc) (Stefano S, patches
posted, needs updates)
* Improved Hotplug script support (Roger Pau Monné, patches
posted)
* Block script support -- follows on from hotplug script (Roger
Pau Monné)
* xs.h -> xenstore.h. Should do this for 4.2 rather than have
distros carry their own patches. (Ian C, patch posted)
hypervisor, nice to have:
* PoD performance improvements (George Dunlap)
tools, nice to have:
* Upstream qemu feature patches:
* Upstream qemu PCI passthrough support (Anthony Perard,
awaiting qemy upstream review)
* Upstream qemu is frozen for their next release.
Unlikely that these will be accepted in the next
few weeks. Given that upstream qemu is not yet
the default I think it is acceptable to defer
PCI passthrough support to 4.3.
* Upstream qemu save restore (Anthony Perard, Stefano
Stabellini, qemu patches applied, libxl patches applied.
Done)
* Initial xl support for Remus (memory checkpoint, blackholing)
(Shriram, was waiting on libxl side of qemu upstream
save/restore, now unblocked)
* xl compatibility with xm:
* xl support for autospawning vncviewer (vncviewer=1 or
otherwise) (Goncalo Gomes, new version of patch posted
recently)
* Directory usage in libxl (Bastian, as part of Debian packaging,
likely to defer to 4.3 unless there is some big problem with
packaging deviating from upstream)
* dumps in /var/xen: wtf?
* Bastian: "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?
* Bastian: "I don't think rebooting the control
domain without rebooting Xen will work right
now. So /var/run is the correct location."
* /var/run/libxl for temporary files
* "$TMPDIR or the fallback /tmp is the correct
location."
* xl commands to help rebind pci devices to pciback.
[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 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> wrote: > tools, blockers:Adjustments needed for qdisk backend to work on non-pvops Linux.> hypervisor, nice to have:IRQ problem for which debugging code got added by c/s 24707:96987c324a4f. I have a tentative adjustment to this which I would hope to at least eliminate the bad consequences of crashing the hypervisor (converting the unsolicited PIC-originated IRQ into a spurious one). I''ll submit as soon as I got to test this a little, particularly also on an old box without APIC. Jan
On Mon, 2012-05-14 at 11:26 +0100, Ian Campbell wrote:> > * xl compatibility with xm: >* `cpus=[2,3]` to select specific mapping vcpu0-->pcpu2, vcpu1-->pcpu3 as xm does. (Dario Faggioli, patches posted and reviewed, will repost) Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell writes ("[Xen-devel] Xen 4.2 TODO / Release
Plan"):> Plan for a 4.2 release:
> http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
...> 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, I think this was actually DONE a while back and
> I missed it)
This is indeed committed.
> * 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.
I have yet to write such a note.
> * libxl_*_path. Majority made internal, only configdir and
> lockdir remain public (used by xl). Good enough?
Yes. We should perhaps add a note saying that the lockdir path
function should not be used by out-of-tree callers.
> * 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. (IanJ).
I am working on this.
> * libxl_domain_create_{new,restore} -- IanJ has
> patches as part of event series, (DONE).
Yes.
> * libxl_domain_core_dump. Can take a dummy ao_how
> and remain synchronous internally. (IanC, DONE)
Yes.
> * libxl_device_{disk,nic,vkb,add,pci}_add (and
> remove?). Roger Pau Monné fixes disk as part of
> hotplug script series and adds infrastructure
> which should make the others trivial. (Roger,
> WIP)
Right.
> * libxl_cdrom_insert. Should be easy once
> disk_{add,remove} done, IanJ to look at (or
> doing so?).
This isn''t on my proximate todo list yet.
> * libxl_device_disk_local_{attach,detach}. Become
> internal as part of Stefano''s domain 0
disk
> attach series (patches posted, another round
> required?)
I believe I am expecting a revised series from Stefano, yes.
> * libxl_fork -- IanJ''s event series will
remove
> all users of this. (DONE)
Yes.
> * xl compatibility with xm:
> * [BUG] cannot create an empty CD-ROM driver on HVM guest,
> reported by Fabio Fantoni in
> <4F9672DD.2080902@tiscali.it>
This needs my attention.
> * does not automatically try to select a (set of) node(s)
> on which to create a VM and pin its vcpus there. (Dario
> Faggioli, patches posted)
This is still in progress somehow ?
> * More formally deprecate xm/xend. Manpage patches already in
> tree. Needs release noting and communication around -rc1 to
> remind people to test xl.
Good.
> * xl to refuse to run if xend is running, Roger Pau Monné (patch
> posted, needs rebase)
Committed.
> * Domain 0 block attach & general hotplug when using qdisk
backend
> (need to start qemu as necessary etc) (Stefano S, patches
> posted, needs updates)
Is this not the same as the libxl_device_disk_local_{attach,detach}
series you mention above ?
> * Improved Hotplug script support (Roger Pau Monné, patches
> posted)
These are currently undergoing review/rework.
> * Block script support -- follows on from hotplug script (Roger
> Pau Monn)
Right.
> * xs.h -> xenstore.h. Should do this for 4.2 rather than have
> distros carry their own patches. (Ian C, patch posted)
I will be applying this today I hope.
> tools, nice to have:
> * Initial xl support for Remus (memory checkpoint, blackholing)
> (Shriram, was waiting on libxl side of qemu upstream
> save/restore, now unblocked)
Yes.
> * xl compatibility with xm:
> * xl support for autospawning vncviewer (vncviewer=1 or
> otherwise) (Goncalo Gomes, new version of patch posted
> recently)
I think we are awaiting a reworked series from Goncalo.
> * Directory usage in libxl (Bastian, as part of Debian packaging,
> likely to defer to 4.3 unless there is some big problem with
> packaging deviating from upstream)
I think this can wait.
Ian.
--===============2543054859318590087=Content-Type: text/plain;
charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
--===============2543054859318590087==--
On Mon, 2012-05-14 at 16:33 +0100, Ian Jackson wrote:> > * libxl_*_path. Majority made internal, only configdir and > > lockdir remain public (used by xl). Good enough? > > Yes. We should perhaps add a note saying that the lockdir path > function should not be used by out-of-tree callers.Or move lockdir into xl, it''s only actually used there. So is config_dir_path now I look at it.> > * libxl_cdrom_insert. Should be easy once > > disk_{add,remove} done, IanJ to look at (or > > doing so?). > > This isn''t on my proximate todo list yet.OK.> > * does not automatically try to select a (set of) node(s) > > on which to create a VM and pin its vcpus there. (Dario > > Faggioli, patches posted) > > This is still in progress somehow ?RFC posted, awaiting another round IIRC.> > * Domain 0 block attach & general hotplug when using qdisk backend > > (need to start qemu as necessary etc) (Stefano S, patches > > posted, needs updates) > > Is this not the same as the libxl_device_disk_local_{attach,detach} > series you mention above ?Yes it is. The first entry was under "make them async if necessary", which noted that this would be fixed by Stefano''s series which was making them internal, which is this second entry.> > * xl compatibility with xm: > > * xl support for autospawning vncviewer (vncviewer=1 or > > otherwise) (Goncalo Gomes, new version of patch posted > > recently) > > I think we are awaiting a reworked series from Goncalo.Yes.> > * Directory usage in libxl (Bastian, as part of Debian packaging, > > likely to defer to 4.3 unless there is some big problem with > > packaging deviating from upstream) > > I think this can wait.Agreed. Ian.
On Mon, 2012-05-14 at 16:33 +0100, Ian Jackson 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> > > This needs my attention. > > > * does not automatically try to select a (set of) node(s) > > on which to create a VM and pin its vcpus there. (Dario > > Faggioli, patches posted) > > This is still in progress somehow ? >It definitely is. I''ve it almost ready but got distracted by some other stuff in the last days... I''ll post something again asap. Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
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.
A lot of new DONE items. The big remaining items are
the hotplug script series and asynchronisation of migration.
If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)
Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.
hypervisor, blockers:
* Performance regression due to contention on p2m lock. (Tim,
Andres, DONE)
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:
* 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). (IanC, to consider
moving the two reamining into xl instead of libxl)
* Interfaces which may need to be async:
* libxl_domain_suspend. Move
xc_domain_save/restore into a separate process
(IanJ, RFC posted).
* libxl_device_{disk,nic,vkb,add,pci}_add (and
remove?). Roger Pau Monné fixes disk as part of
hotplug script series and adds infrastructure
which should make the others trivial. (Roger,
WIP)
* libxl_cdrom_insert. Should be easy once
disk_{add,remove} done. Nobody is looking at
this?
* libxl_device_disk_local_{attach,detach}. Become
internal as part of Stefano's domain 0 disk
attach series (already tracked below, "Domain 0
block attach & general hotplug", will remove
this entry instance from next weeks list in
favour of that one)
* xl compatibility with xm:
* [BUG] cannot create an empty CD-ROM driver on HVM guest,
reported by Fabio Fantoni in
<4F9672DD.2080902@tiscali.it>
* does not automatically try to select a (set of) node(s)
on which to create a VM and pin its vcpus there. (Dario
Faggioli, patches posted)
* `cpus=[2,3]` to select specific mapping vcpu0-->pcpu2,
vcpu1-->pcpu3 as xm does. (Dario Faggioli, patches
posted and reviewed, will repost)
* [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". ("George will do it if no one else steps
up")
* 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é (DONE)
* Domain 0 block attach & general hotplug when using qdisk backend
(need to start qemu as necessary etc) (Stefano S, patches
posted, needs updates)
* Improved Hotplug script support (Roger Pau Monné, patches
posted)
* Block script support -- follows on from hotplug script (Roger
Pau Monné)
* xs.h -> xenstore.h. Should do this for 4.2 rather than have
distros carry their own patches. (Ian C, DONE)
* Adjustments needed for qdisk backend to work on non-pvops Linux.
(Jan Beulich)
hypervisor, nice to have:
* PoD performance improvements (George Dunlap)
* IRQ problem for which debugging code got added by c/s
24707:96987c324a4f. I have a tentative adjustment to this which
I would hope to at least eliminate the bad consequences of
crashing the hypervisor (converting the unsolicited
PIC-originated IRQ into a spurious one). I'll submit as soon as
I got to test this a little, particularly also on an old box
without APIC. (Jan Beulich)
tools, nice to have:
* Upstream qemu feature patches:
* Upstream qemu PCI passthrough support (Anthony Perard,
awaiting qemy upstream review)
* Upstream qemu is frozen for their next release.
Unlikely that these will be accepted in the next
few weeks. Defered until 4.3 (therefore DONE in
this context)
* Initial xl support for Remus (memory checkpoint,
blackholing) (Shriram, DONE)
* xl compatibility with xm:
* xl support for autospawning vncviewer (vncviewer=1 or
otherwise) (Goncalo Gomes, DONE)
* Directory usage in libxl (Bastian, as part of Debian packaging).
Defer to 4.3, therefore DONE in this context.
* dumps in /var/xen: wtf?
* Bastian: "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?
* Bastian: "I don't think rebooting the control
domain without rebooting Xen will work right
now. So /var/run is the correct location."
* /var/run/libxl for temporary files
* "$TMPDIR or the fallback /tmp is the correct
location."
* xl commands to help rebind pci devices to pciback. (George
Dunlap, DONE)
* libxl: Add API to retrieve domain console tty (Bamvor Jian
Zhang, patches posted)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, May 21, 2012 at 12:47:37PM +0100, Ian Campbell wrote:> > tools, nice to have: > * Upstream qemu feature patches: > * Upstream qemu PCI passthrough support (Anthony Perard, > awaiting qemy upstream review) > * Upstream qemu is frozen for their next release. > Unlikely that these will be accepted in the next > few weeks. Defered until 4.3 (therefore DONE in > this context) > * Initial xl support for Remus (memory checkpoint, > blackholing) (Shriram, DONE) > * xl compatibility with xm: > * xl support for autospawning vncviewer (vncviewer=1 or > otherwise) (Goncalo Gomes, DONE) > * Directory usage in libxl (Bastian, as part of Debian packaging). > Defer to 4.3, therefore DONE in this context. > * dumps in /var/xen: wtf? > * Bastian: "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? > * Bastian: "I don''t think rebooting the control > domain without rebooting Xen will work right > now. So /var/run is the correct location." > * /var/run/libxl for temporary files > * "$TMPDIR or the fallback /tmp is the correct > location." > * xl commands to help rebind pci devices to pciback. (George > Dunlap, DONE) > * libxl: Add API to retrieve domain console tty (Bamvor Jian > Zhang, patches posted) >* xl.cfg(5) documentation patch for qemu-upstream videoram/videomem support: http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html qemu-upstream doesn''t support specifying videomem size for the HVM guest cirrus/stdvga. (but this works with qemu-xen-traditional). -- Pasi
On Mon, 2012-05-21 at 14:00 +0100, Pasi Kärkkäinen wrote:> * xl.cfg(5) documentation patch for qemu-upstream videoram/videomem support: > http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html > qemu-upstream doesn't support specifying videomem size for the HVM guest cirrus/stdvga. > (but this works with qemu-xen-traditional).Would you be able to put that into patch form please? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 21.05.12 at 13:47, Ian Campbell <Ian.Campbell@citrix.com> wrote: > * IRQ problem for which debugging code got added by c/s > 24707:96987c324a4f. I have a tentative adjustment to this which > I would hope to at least eliminate the bad consequences of > crashing the hypervisor (converting the unsolicited > PIC-originated IRQ into a spurious one). I''ll submit as soon as > I got to test this a little, particularly also on an old box > without APIC. (Jan Beulich)That adjustment is already in (25336:edd7c7ad1ad2). But there''s still the issue of xfree() being called from interrupt context, for which Andy Cooper had posted a patch, while I later suggested to address the issue in a more general form. No feedback from Keir so far, so perhaps I should go ahead and submit the adjustment in more formal shape. Jan
On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote:> > >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> > wrote: > > tools, blockers: > > Adjustments needed for qdisk backend to work on non-pvops Linux.Can you remind me what those are please. Do they touch libxl or libxc? Thanks, Ian.
>>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote: >> >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> >> wrote: >> > tools, blockers: >> >> Adjustments needed for qdisk backend to work on non-pvops Linux. > > Can you remind me what those are please."qemu/xendisk: set maximum number of grants to be used" (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html). Unfortunately I didn''t hear back from Olaf regarding the updated value that the supposed v2 of the patch (see the thread), which is at least partly due to him having further problems with the qdisk backend. Olaf - did you ever see gntdev allocation failures again after switching to the higher value?> Do they touch libxl or libxc?The libxc touching one went in already (25330:49ce39c88aee). Jan
On Tue, May 29, Jan Beulich wrote:> >>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote: > >> > >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> > >> wrote: > >> > tools, blockers: > >> > >> Adjustments needed for qdisk backend to work on non-pvops Linux. > > > > Can you remind me what those are please. > > "qemu/xendisk: set maximum number of grants to be used" > (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html). > > Unfortunately I didn''t hear back from Olaf regarding the updated > value that the supposed v2 of the patch (see the thread), which > is at least partly due to him having further problems with the qdisk > backend. Olaf - did you ever see gntdev allocation failures again > after switching to the higher value?I just did a successful installation of sles11sp2 guest on a xen-unstable host with changeset 25427:ad348c6575b8, and with the change below, and the second attempt I just started seems get through as well. I''m sure I used this variant already two weeks ago, and the install still failed. Perhaps other changes made during the last two weeks make a difference. I will also doublecheck how it goes without this change. Olaf --- a/hw/xen_disk.c +++ b/hw/xen_disk.c @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * if (xen_mode != XEN_EMULATE) { batch_maps = 1; } + if (xc_gnttab_set_max_grants(xendev->gnttabdev, + 2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", + strerror(errno)); } static int blk_init(struct XenDevice *xendev)
>>> On 31.05.12 at 11:24, Olaf Hering <olaf@aepfle.de> wrote: > On Tue, May 29, Jan Beulich wrote: > >> >>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote: >> >> >> >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> >> >> wrote: >> >> > tools, blockers: >> >> >> >> Adjustments needed for qdisk backend to work on non-pvops Linux. >> > >> > Can you remind me what those are please. >> >> "qemu/xendisk: set maximum number of grants to be used" >> (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html). >> >> Unfortunately I didn''t hear back from Olaf regarding the updated >> value that the supposed v2 of the patch (see the thread), which >> is at least partly due to him having further problems with the qdisk >> backend. Olaf - did you ever see gntdev allocation failures again >> after switching to the higher value? > > I just did a successful installation of sles11sp2 guest on a > xen-unstable host with changeset 25427:ad348c6575b8, and with the change > below, and the second attempt I just started seems get through as well. > > I''m sure I used this variant already two weeks ago, and the install > still failed. Perhaps other changes made during the last two weeks make > a difference.That would be odd.> I will also doublecheck how it goes without this change. > > Olaf > > --- a/hw/xen_disk.c > +++ b/hw/xen_disk.c > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > if (xen_mode != XEN_EMULATE) { > batch_maps = 1; > } > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > + 2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0)The + 1 at the end is certainly not needed anymore after the doubling.> + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", > + strerror(errno)); > } > > static int blk_init(struct XenDevice *xendev)So I think I''ll re-submit with the doubled values then. That''s in any case better than not setting an upper limit at all on those older kernels. Jan
On Thu, 31 May 2012, Jan Beulich wrote:> >>> On 31.05.12 at 11:24, Olaf Hering <olaf@aepfle.de> wrote: > > On Tue, May 29, Jan Beulich wrote: > > > >> >>> On 29.05.12 at 11:32, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> > On Mon, 2012-05-14 at 12:14 +0100, Jan Beulich wrote: > >> >> > >> >> >>> On 14.05.12 at 12:26, Ian Campbell <Ian.Campbell@citrix.com> > >> >> wrote: > >> >> > tools, blockers: > >> >> > >> >> Adjustments needed for qdisk backend to work on non-pvops Linux. > >> > > >> > Can you remind me what those are please. > >> > >> "qemu/xendisk: set maximum number of grants to be used" > >> (http://lists.xen.org/archives/html/xen-devel/2012-05/msg00715.html). > >> > >> Unfortunately I didn''t hear back from Olaf regarding the updated > >> value that the supposed v2 of the patch (see the thread), which > >> is at least partly due to him having further problems with the qdisk > >> backend. Olaf - did you ever see gntdev allocation failures again > >> after switching to the higher value? > > > > I just did a successful installation of sles11sp2 guest on a > > xen-unstable host with changeset 25427:ad348c6575b8, and with the change > > below, and the second attempt I just started seems get through as well. > > > > I''m sure I used this variant already two weeks ago, and the install > > still failed. Perhaps other changes made during the last two weeks make > > a difference. > > That would be odd. > > > I will also doublecheck how it goes without this change. > > > > Olaf > > > > --- a/hw/xen_disk.c > > +++ b/hw/xen_disk.c > > @@ -536,6 +536,10 @@ static void blk_alloc(struct XenDevice * > > if (xen_mode != XEN_EMULATE) { > > batch_maps = 1; > > } > > + if (xc_gnttab_set_max_grants(xendev->gnttabdev, > > + 2 * max_requests * BLKIF_MAX_SEGMENTS_PER_REQUEST + 1) < 0) > > The + 1 at the end is certainly not needed anymore after the > doubling. > > > + xen_be_printf(xendev, 0, "xc_gnttab_set_max_grants failed: %s\n", > > + strerror(errno)); > > } > > > > static int blk_init(struct XenDevice *xendev) > > So I think I''ll re-submit with the doubled values then. That''s > in any case better than not setting an upper limit at all on those > older kernels.At this point I would prefer that you defined a MAX_GRANT_REQS constant and added a comment to explain what is for, and why it is set to (2 * max_requests).
On Thu, May 31, Olaf Hering wrote:> I just did a successful installation of sles11sp2 guest on a > xen-unstable host with changeset 25427:ad348c6575b8, and with the change > below, and the second attempt I just started seems get through as well. > > I''m sure I used this variant already two weeks ago, and the install > still failed. Perhaps other changes made during the last two weeks make > a difference. > > I will also doublecheck how it goes without this change.Without such a change an installation fails already in the disk partitioning stage with IO errors in the guest. With v3 of your patch installation works for me. Olaf
A bit late this week, due to my being on vacation. I'm on vacation
next two Monday as well so it will be late then too.
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
When It's Ready -- First release candidate
Weekly -- RCN+1 until release
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.
If you are aware of any bugs which must/should be fixed for 4.2 then
please reply to this thread (otherwise I may not remember to pick them
up next week)
Other than that I think we should consider the freeze to be in full
effect and the bar to entry to 4.2 to be very high.
hypervisor, blockers:
* None
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:
* LIBXL_NIC_TYPE enum names are confusing.
* Interfaces which may need to be async:
* libxl_domain_suspend. Move xc_domain_save/restore into a
separate process (IanJ, patches posted).
* libxl_device_{disk,nic,vkb,add,pci}_add (and
remove). (Roger, patches posted for disk & nic, vkb
trivial, not looked at pci yet)
* use libxl_cpumap for b_info.avail_cpus instead of an int,
this"allows setting more than 31 CPUS (Yang Z Zhang, patches
posted)
* use an enum for VGA interface type (e.g. Cirrus,
StdVGA). Allows for QXL support (in 4.3). (Zhou Peng,
patches posted)
* xl compatibility with xm:
* [BUG] cannot create an empty CD-ROM drive on HVM guest,
reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it>
* does not automatically try to select a (set of) node(s) on
which to create a VM and pin its vcpus there. (Dario
Faggioli, patches reposted, under review)
* More formally deprecate xm/xend. Manpage patches already in
tree. Needs release noting and communication around -rc1 to
remind people to test xl.
* calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau
Monné, patches posted)
* Block script support -- follows on from hotplug script (Roger
Pau Monné, "just be a matter of removing an "if"")
* Adjustments needed for qdisk backend to work on non-pvops Linux.
"qemu/xendisk: set maximum number of grants to be used" (Jan
Beulich)
* Confirm that migration from Xen 4.1 -> 4.2 works...
* [BUG] Build failure due to gcc -Wswitch on some distros
vs. LIBXL_DOMAIN_TYPE. (Dario Faggioli, DONE)
hypervisor, nice to have:
* PoD performance improvements (George Dunlap, patches posted)
tools, nice to have:
* xl compatibility with xm:
* Accept "xl cr /dev/null param=value" to provide all config
on the command line (W. Michael Petullo, patch posted)
* libxl: Add API to retrieve domain console tty (Bamvor Jian
Zhang, DONE)
* libxl stable API
* libxl_wait_for_free_memory/libxl_wait_for_memory_target.
Interface needs an overhaul, related to
locking/serialization over domain create. IanJ to add note
about this interface being substandard but otherwise defer
to 4.3.
* Interfaces which may need to be async:
* libxl_cdrom_insert. Should be easy once
disk_{add,remove} done. This is basically a helper
function and its functionality can be implemented in
terms of the libxl_disk_* interfaces. If this is not
done in time we should document as a substandard
interface which is subject to change post 4.2.
* xl.cfg(5) documentation patch for qemu-upstream
videoram/videomem support:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
qemu-upstream doesn't support specifying videomem size for the
HVM guest cirrus/stdvga. (but this works with
qemu-xen-traditional). (Pasi Kärkkäinen)
* qemu-upstream for NetBSD (Roger)
* [BUG] long stop during the guest boot process with qcow image,
reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821
* [BUG] vcpu-set doesn't take effect on guest, reported by Intel:
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
* Load blktap driver from xencommons initscript if available, thread at:
<db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
properly in 4.3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: > tools, blockers: > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich)Patch was posted and is in upstream qemu, just needs pulling back into our two clones. Jan
On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote:> >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > tools, blockers: > > > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > > "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich) > > Patch was posted and is in upstream qemu, just needs pulling back > into our two clones.Thanks. CCing Stefano to be sure he knows that... Ian.
On Tue, 12 Jun 2012, Ian Campbell wrote:> On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote: > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > tools, blockers: > > > > > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > > > "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich) > > > > Patch was posted and is in upstream qemu, just needs pulling back > > into our two clones. > > Thanks. CCing Stefano to be sure he knows that...qemu-upstream-unstable has been updated, Ian is responsible for qemu-xen-unstable.
Ian Campbell wrote:> A bit late this week, due to my being on vacation. I'm on vacation > next two Monday as well so it will be late then too. > > 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 > When It's Ready -- First release candidate > Weekly -- RCN+1 until release > > 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. > > If you are aware of any bugs which must/should be fixed for 4.2 then > please reply to this thread (otherwise I may not remember to pick them > up next week) > > Other than that I think we should consider the freeze to be in full > effect and the bar to entry to 4.2 to be very high. > > hypervisor, blockers: > > * None > > 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: > > * LIBXL_NIC_TYPE enum names are confusing. > > * Interfaces which may need to be async: > > * libxl_domain_suspend. Move xc_domain_save/restore into a > separate process (IanJ, patches posted). > > * libxl_device_{disk,nic,vkb,add,pci}_add (and > remove). (Roger, patches posted for disk& nic, vkb > trivial, not looked at pci yet) > > * use libxl_cpumap for b_info.avail_cpus instead of an int, > this"allows setting more than 31 CPUS (Yang Z Zhang, patches > posted) > > * use an enum for VGA interface type (e.g. Cirrus, > StdVGA). Allows for QXL support (in 4.3). (Zhou Peng, > patches posted) > > * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM drive on HVM guest, > reported by Fabio Fantoni in<4F9672DD.2080902@tiscali.it> > > * does not automatically try to select a (set of) node(s) on > which to create a VM and pin its vcpus there. (Dario > Faggioli, patches reposted, under review) > > * More formally deprecate xm/xend. Manpage patches already in > tree. Needs release noting and communication around -rc1 to > remind people to test xl. > > * calling hotplug scripts from xl (Linux and NetBSD) (Roger Pau > Monné, patches posted)Another round posted (v6), waiting for review.> > * Block script support -- follows on from hotplug script (Roger > Pau Monné, "just be a matter of removing an "if"") > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich) > > * Confirm that migration from Xen 4.1 -> 4.2 works... > > * [BUG] Build failure due to gcc -Wswitch on some distros > vs. LIBXL_DOMAIN_TYPE. (Dario Faggioli, DONE) > > hypervisor, nice to have: > > * PoD performance improvements (George Dunlap, patches posted) > > tools, nice to have: > > * xl compatibility with xm: > > * Accept "xl cr /dev/null param=value" to provide all config > on the command line (W. Michael Petullo, patch posted) > > * libxl: Add API to retrieve domain console tty (Bamvor Jian > Zhang, DONE) > > * libxl stable API > > * libxl_wait_for_free_memory/libxl_wait_for_memory_target. > Interface needs an overhaul, related to > locking/serialization over domain create. IanJ to add note > about this interface being substandard but otherwise defer > to 4.3. > > * Interfaces which may need to be async: > > * libxl_cdrom_insert. Should be easy once > disk_{add,remove} done. This is basically a helper > function and its functionality can be implemented in > terms of the libxl_disk_* interfaces. If this is not > done in time we should document as a substandard > interface which is subject to change post 4.2. > > * xl.cfg(5) documentation patch for qemu-upstream > videoram/videomem support: > http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html > qemu-upstream doesn't support specifying videomem size for the > HVM guest cirrus/stdvga. (but this works with > qemu-xen-traditional). (Pasi Kärkkäinen) > > * qemu-upstream for NetBSD (Roger)Patch committed to netbsd kernel, awaiting approval.> > * [BUG] long stop during the guest boot process with qcow image, > reported by Intel: http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1821 > > * [BUG] vcpu-set doesn't take effect on guest, reported by Intel: > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822 > > * Load blktap driver from xencommons initscript if available, thread at: > <db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more > properly in 4.3 > > > > > _______________________________________________ > 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
On Tue, 2012-06-12 at 14:00 +0100, Ian Campbell wrote:> * xl compatibility with xm: > > * [BUG] cannot create an empty CD-ROM drive on HVM guest, > reported by Fabio Fantoni in <4F9672DD.2080902@tiscali.it> > > * does not automatically try to select a (set of) node(s) on > which to create a VM and pin its vcpus there. (Dario > Faggioli, patches reposted, under review) >v2 posted last Friday. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:> On Tue, 12 Jun 2012, Ian Campbell wrote: > > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote: > > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > > tools, blockers: > > > > > > > > * Adjustments needed for qdisk backend to work on non-pvops Linux. > > > > "qemu/xendisk: set maximum number of grants to be used" (Jan Beulich) > > > > > > Patch was posted and is in upstream qemu, just needs pulling back > > > into our two clones. > > > > Thanks. CCing Stefano to be sure he knows that... > > qemu-upstream-unstable has been updated, Ian is responsible for > qemu-xen-unstable.I was about to ping Ian J about this, because there seems to be breakage which would be fixed by this (Olaf: "grant table errors with qemu-xen-traditional" today) but it looks like these patches weren''t actually submitted against the traditional tree? Or at least I can''t find any such thing. Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply as is to the trad tree? Has any one tried running it? Is this what Olaf tested in the thread referenced above? That thread also references <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which should be applied to the trad tree too. Has anyone tested that combo? I can see how Ian missed this -- it very much looked like those two patches were for qemu-upstream only to me (from the subject, cc line etc etc). Ian.
>>> On 20.06.12 at 17:25, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote: >> On Tue, 12 Jun 2012, Ian Campbell wrote: >> > On Tue, 2012-06-12 at 14:57 +0100, Jan Beulich wrote: >> > > >>> On 12.06.12 at 15:00, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > > > tools, blockers: >> > > > >> > > > * Adjustments needed for qdisk backend to work on non-pvops Linux. >> > > > "qemu/xendisk: set maximum number of grants to be used" (Jan > Beulich) >> > > >> > > Patch was posted and is in upstream qemu, just needs pulling back >> > > into our two clones. >> > >> > Thanks. CCing Stefano to be sure he knows that... >> >> qemu-upstream-unstable has been updated, Ian is responsible for >> qemu-xen-unstable. > > I was about to ping Ian J about this, because there seems to be breakage > which would be fixed by this (Olaf: "grant table errors with > qemu-xen-traditional" today) but it looks like these patches weren''t > actually submitted against the traditional tree? Or at least I can''t > find any such thing. > > Does the patch in <4FC770E20200007800087298@nat28.tlf.novell.com> apply > as is to the trad tree? Has any one tried running it? Is this what Olaf > tested in the thread referenced above?Apparently yes, except that the change did get applied to the wrong function (and hence didn''t work).> That thread also references > <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which > should be applied to the trad tree too. Has anyone tested that combo? > > I can see how Ian missed this -- it very much looked like those two > patches were for qemu-upstream only to me (from the subject, cc line etc > etc).I didn''t think that I needed to formally submit patches that were requested to be ported over to -traditional when they already went into upstream qemu. If I''m wrong with this, then please let me know and I''ll submit both patches asap. Jan
Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release
Plan"):> On Wed, 2012-06-13 at 11:48 +0100, Stefano Stabellini wrote:
> > qemu-upstream-unstable has been updated, Ian is responsible for
> > qemu-xen-unstable.
Sorry, I had this message marked to go back to but...
> I was about to ping Ian J about this, because there seems to be breakage
> which would be fixed by this (Olaf: "grant table errors with
> qemu-xen-traditional" today) but it looks like these patches
weren''t
> actually submitted against the traditional tree? Or at least I
can''t
> find any such thing.
...indeed I wasn''t sure what it was referring to.
Thanks,
Ian.
Jan Beulich writes ("Re: [Xen-devel] Xen 4.2 TODO / Release
Plan"):> I didn''t think that I needed to formally submit patches that were
> requested to be ported over to -traditional when they already
> went into upstream qemu. If I''m wrong with this, then please let
> me know and I''ll submit both patches asap.
Certainly there is nothing automatic (people or computers) that fishes
changes to qemu upstream into -traditional. If you want something
committed to qemu-xen-traditional you''ll have to say so.
Ian.
On Wed, 2012-06-20 at 16:40 +0100, Jan Beulich wrote:> > That thread also references > > <4FABFCF40200007800082CE0@nat28.tlf.novell.com> as something which > > should be applied to the trad tree too. Has anyone tested that combo? > > > > I can see how Ian missed this -- it very much looked like those two > > patches were for qemu-upstream only to me (from the subject, cc line etc > > etc). > > I didn''t think that I needed to formally submit patches that were > requested to be ported over to -traditional when they already > went into upstream qemu. If I''m wrong with this, then please let > me know and I''ll submit both patches asap.This is really for Ian J to say but IMHO the two code bases have diverged enough that blindly pulling from upstream -> traditional is not a good idea, so at the least the change needs to be tested in that context. Even if we were happy to just pull things in then the mail needs to note somewhere which tree(s) the patch should be applied to. Ian.
Ian Campbell writes ("Re: [Xen-devel] Xen 4.2 TODO / Release
Plan"):> This is really for Ian J to say but IMHO the two code bases have
> diverged enough that blindly pulling from upstream -> traditional is not
> a good idea, so at the least the change needs to be tested in that
> context.
Indeed. I would like someone to at least have looked at the automatic
merge output from a cherry pick.
Ian.
>>> On 20.06.12 at 17:47, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] Xen 4.2 TODO / Release Plan"): >> I didn''t think that I needed to formally submit patches that were >> requested to be ported over to -traditional when they already >> went into upstream qemu. If I''m wrong with this, then please let >> me know and I''ll submit both patches asap. > > Certainly there is nothing automatic (people or computers) that fishes > changes to qemu upstream into -traditional. If you want something > committed to qemu-xen-traditional you''ll have to say so.I''m not talking about anything automatic here. The need for pulling the change over was pointed out a number of times by both Stefano and me. Anyway - do you need a formal patch submission, or can you just pull out the one important and possibly one secondary commits? Jan