All, with the goal of releasing by the end of next week (with little of no further changes) - please test! Thanks, Jan
On 30/08/13 11:14, Jan Beulich wrote:> All, > > with the goal of releasing by the end of next week (with little of no > further changes) - please test! > > Thanks, JanLooking through the list of patches backported in XenServer, Ian: Can I strongly recommend 704302ce9404c73cfb687d31adcf67094ab5bb53 "oxenstored: Protect oxenstored from malicious domains." for backport to all trees. Jan: Can I suggest possibly: * fca11da0ec956b17d7450d7776c3ffa22a8f538a "x86: Special case __HYPERVISOR_iret rather more when writing hypercall pages" * 3e787021fb2420851c7bdc3911ea53c728ba5ac0 "x86/Intel: add support for Haswell CPU models" As a group - more detail in the console ring in the case of a crash: * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to console ring even if console lock is busted" * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up writing to the console ring" As a group - improvements around console_force_unlock(): * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s c8177e691f" * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always disable watchdog in console_force_unlock()" * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak implementation given new common code" * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from being x86 specific to common code" ~Andrew
Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have
been tagged"):> On 30/08/13 11:14, Jan Beulich wrote:
> Can I strongly recommend 704302ce9404c73cfb687d31adcf67094ab5bb53
> "oxenstored: Protect oxenstored from malicious domains." for
backport to
> all trees.
Done (to 4.3, 4.2, 4.1).
Ian.
On 03/09/13 12:05, Ian Jackson wrote:> Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged"): >> On 30/08/13 11:14, Jan Beulich wrote: >> Can I strongly recommend 704302ce9404c73cfb687d31adcf67094ab5bb53 >> "oxenstored: Protect oxenstored from malicious domains." for backport to >> all trees. > Done (to 4.3, 4.2, 4.1). > > Ian.Further to this, can I recommend * 258d27a1d9fb33a490bef1381f52d522225c3dca "pygrub: add Debian extlinux.conf path" * d513814db6af2b298b8776d7ffc5fb1261e176f4 "pygrub/GrubConf: fix boot problem for fedora 19 grub.cfg" * e892ab5ad4238efc1c425ac7a28581c116e674af "pygrub: add fedora 19 grub.cfg example" Which are all pygrub fixes for booting newer PV guests. ~Andrew
Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have
been tagged"):> Further to this, can I recommend
>
> * 258d27a1d9fb33a490bef1381f52d522225c3dca "pygrub: add Debian
> extlinux.conf path"
Done. (4.3, 4.2, 4.1; 4.1 had a conflict which I fixed up.)
> * d513814db6af2b298b8776d7ffc5fb1261e176f4 "pygrub/GrubConf: fix boot
> problem for fedora 19 grub.cfg"
The corresponding code doesn''t seem to exist in 4.3 and earlier.
> * e892ab5ad4238efc1c425ac7a28581c116e674af "pygrub: add fedora 19
> grub.cfg example"
This is a docs change which is probably not worth backporting.
Thanks,
Ian.
On Tue, 2013-09-03 at 15:48 +0100, Ian Jackson wrote:> Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged"):> > * d513814db6af2b298b8776d7ffc5fb1261e176f4 "pygrub/GrubConf: fix boot > > problem for fedora 19 grub.cfg" > > The corresponding code doesn''t seem to exist in 4.3 and earlier. > > > * e892ab5ad4238efc1c425ac7a28581c116e674af "pygrub: add fedora 19 > > grub.cfg example" > > This is a docs change which is probably not worth backporting.It''s also a (manually driven) test case, which might have been interesting if the previous patch had applied, to confirm it was working... rune: python ./tools/pygrub/src/GrubConf.py grub2 tools/pygrub/examples/fedora-19.grub2 Ian.
Jan, just double checking you mean the goal is to release by this Friday the 6th? Am a little tight on cycles, but will be able to help with blog post, xen-announce, uploading binaries to the site, if Ian Jackson is around to do the tarballs. Lars On Tue, Sep 3, 2013 at 3:58 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Tue, 2013-09-03 at 15:48 +0100, Ian Jackson wrote: > > Andrew Cooper writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have > been tagged"): > > > > * d513814db6af2b298b8776d7ffc5fb1261e176f4 "pygrub/GrubConf: fix boot > > > problem for fedora 19 grub.cfg" > > > > The corresponding code doesn''t seem to exist in 4.3 and earlier. > > > > > * e892ab5ad4238efc1c425ac7a28581c116e674af "pygrub: add fedora 19 > > > grub.cfg example" > > > > This is a docs change which is probably not worth backporting. > > It''s also a (manually driven) test case, which might have been > interesting if the previous patch had applied, to confirm it was > working... > > rune: > python ./tools/pygrub/src/GrubConf.py grub2 > tools/pygrub/examples/fedora-19.grub2 > > Ian. > > > _______________________________________________ > 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 02.09.13 at 20:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > Can I suggest possibly: > > * fca11da0ec956b17d7450d7776c3ffa22a8f538a "x86: Special case > __HYPERVISOR_iret rather more when writing hypercall pages" > * 3e787021fb2420851c7bdc3911ea53c728ba5ac0 "x86/Intel: add support for > Haswell CPU models" > > As a group - more detail in the console ring in the case of a crash: > * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to > console ring even if console lock is busted" > * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up > writing to the console ring" > > As a group - improvements around console_force_unlock(): > * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s > c8177e691f" > * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always > disable watchdog in console_force_unlock()" > * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak > implementation given new common code" > * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from > being x86 specific to common code"Not at this point anymore; I''ll take a close look for 4.2.4. Jan
>>> On 03.09.13 at 17:36, Lars Kurth <lars.kurth.xen@gmail.com> wrote: > just double checking you mean the goal is to release by this Friday the > 6th?Yes, that''s the plan, albeit with the master branch having been stuck for a number of days (and there being one or two things I would have wanted to pull over) I''m not certain we can achieve this.> Am a little tight on cycles, but will be able to help with blog post, > xen-announce, uploading binaries to the site, if Ian Jackson is around to > do the tarballs.Since he did so in the past, I assume he''ll be able to as long as he''s in the office. I can''t speak for him, though. Jan
Jan Beulich writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have been
tagged"):> On 03.09.13 at 17:36, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> > Am a little tight on cycles, but will be able to help with blog post,
> > xen-announce, uploading binaries to the site, if Ian Jackson is around
to
> > do the tarballs.
>
> Since he did so in the past, I assume he''ll be able to as long as
he''s
> in the office. I can''t speak for him, though.
Yes, I can do that.
Ian.
Jan, will this be happening today? Or are we slipping top next week? Lars On 04/09/2013 11:33, Ian Jackson wrote:> Jan Beulich writes ("Re: [Xen-devel] Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged"): >> On 03.09.13 at 17:36, Lars Kurth <lars.kurth.xen@gmail.com> wrote: >>> Am a little tight on cycles, but will be able to help with blog post, >>> xen-announce, uploading binaries to the site, if Ian Jackson is around to >>> do the tarballs. >> Since he did so in the past, I assume he''ll be able to as long as he''s >> in the office. I can''t speak for him, though. > Yes, I can do that. > > Ian.
>>> On 06.09.13 at 14:31, Lars Kurth <lars.kurth@xen.org> wrote: > will this be happening today? Or are we slipping top next week?Early next week. I''m just now in the process of pulling in the few more changes I wanted from -unstable, now that we at least got an almost-push. Also, qemu tree tagging needs to be happening up front. Jan
>>> On 02.09.13 at 20:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > As a group - more detail in the console ring in the case of a crash: > * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to > console ring even if console lock is busted" > * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up > writing to the console ring"I can see the value of the latter, but the former seems to be pure cleanup (which we don''t normally backport).> As a group - improvements around console_force_unlock(): > * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s > c8177e691f" > * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always > disable watchdog in console_force_unlock()" > * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak > implementation given new common code" > * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from > being x86 specific to common code"The real meat here is the second one, and for a backport I''d prefer to limit the change to this, even if that means that we''ll have to add an #ifdef CONFIG_X86 to common code. Jan
Jan Beulich
2013-Sep-26 08:08 UTC
Ping: backport proposals (was: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged)
>>> On 12.09.13 at 11:11, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 02.09.13 at 20:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> As a group - more detail in the console ring in the case of a crash: >> * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to >> console ring even if console lock is busted" >> * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up >> writing to the console ring" > > I can see the value of the latter, but the former seems to be pure > cleanup (which we don''t normally backport). > >> As a group - improvements around console_force_unlock(): >> * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s >> c8177e691f" >> * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always >> disable watchdog in console_force_unlock()" >> * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak >> implementation given new common code" >> * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from >> being x86 specific to common code" > > The real meat here is the second one, and for a backport I''d > prefer to limit the change to this, even if that means that we''ll > have to add an #ifdef CONFIG_X86 to common code.I was expecting some sort of response to this from you; silence meaning to me that you don''t care anymore... Jan
On 26/09/13 09:08, Jan Beulich wrote:>>>> On 12.09.13 at 11:11, "Jan Beulich" <JBeulich@suse.com> wrote: >>>>> On 02.09.13 at 20:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> As a group - more detail in the console ring in the case of a crash: >>> * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to >>> console ring even if console lock is busted" >>> * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up >>> writing to the console ring" >> I can see the value of the latter, but the former seems to be pure >> cleanup (which we don''t normally backport). >> >>> As a group - improvements around console_force_unlock(): >>> * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s >>> c8177e691f" >>> * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always >>> disable watchdog in console_force_unlock()" >>> * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak >>> implementation given new common code" >>> * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from >>> being x86 specific to common code" >> The real meat here is the second one, and for a backport I''d >> prefer to limit the change to this, even if that means that we''ll >> have to add an #ifdef CONFIG_X86 to common code. > I was expecting some sort of response to this from you; silence > meaning to me that you don''t care anymore... > > Jan >Apologies - the silence is accidental not deliberate. Having the #ifdef in console_force_unlock() would be a substantially smaller and safer backport with the same effect. Would you like me to do a patch for that or are you ok doing it as part of the backport? ~Andrew
>>> On 26.09.13 at 11:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 26/09/13 09:08, Jan Beulich wrote: >>>>> On 12.09.13 at 11:11, "Jan Beulich" <JBeulich@suse.com> wrote: >>>>>> On 02.09.13 at 20:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>>> As a group - more detail in the console ring in the case of a crash: >>>> * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to >>>> console ring even if console lock is busted" >>>> * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up >>>> writing to the console ring" >>> I can see the value of the latter, but the former seems to be pure >>> cleanup (which we don''t normally backport). >>> >>>> As a group - improvements around console_force_unlock(): >>>> * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s >>>> c8177e691f" >>>> * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always >>>> disable watchdog in console_force_unlock()" >>>> * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak >>>> implementation given new common code" >>>> * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from >>>> being x86 specific to common code" >>> The real meat here is the second one, and for a backport I''d >>> prefer to limit the change to this, even if that means that we''ll >>> have to add an #ifdef CONFIG_X86 to common code. >> I was expecting some sort of response to this from you; silence >> meaning to me that you don''t care anymore... > > Apologies - the silence is accidental not deliberate. > > Having the #ifdef in console_force_unlock() would be a substantially > smaller and safer backport with the same effect. > > Would you like me to do a patch for that or are you ok doing it as part > of the backport?Doing this myself is quite okay, I just wanted to see whether you''re fine with me limiting the amount of backporting in both above cases to just the core portions of the changes. Jan
>>> On 26.09.13 at 11:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 26/09/13 09:08, Jan Beulich wrote: >>>>> On 12.09.13 at 11:11, "Jan Beulich" <JBeulich@suse.com> wrote: >>>>>> On 02.09.13 at 20:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>>> As a group - more detail in the console ring in the case of a crash: >>>> * 66450c1d1ab3c4480bbba949113b95d1ab6a943a "xen/conring: Write to >>>> console ring even if console lock is busted" >>>> * cc90bf1894daf9f97791495e2256e7e342e25704 "xen/conring: Clean up >>>> writing to the console ring" >>> I can see the value of the latter, but the former seems to be pure >>> cleanup (which we don''t normally backport).This should have said "former" rather than "latter", and you not further commenting makes me imply that you understood it that way too, and I''ll then go an pull in only the first one.>>>> As a group - improvements around console_force_unlock(): >>>> * 44db24103ff1c53a13afebf4d72ad853cee07786 "fix gdbstub build c/s >>>> c8177e691f" >>>> * 7b9fa702ca323164d6b49e8b639a57f880454a8c "watchdog/crash: Always >>>> disable watchdog in console_force_unlock()" >>>> * 896934596614b44c20a37263c9decb0b639ef995 "x86/watchdog: Tweak >>>> implementation given new common code" >>>> * c8177e691f0f611240853326712d43482ec949bf "watchdog: Move watchdog from >>>> being x86 specific to common code" >>> The real meat here is the second one, and for a backport I''d >>> prefer to limit the change to this, even if that means that we''ll >>> have to add an #ifdef CONFIG_X86 to common code. >> I was expecting some sort of response to this from you; silence >> meaning to me that you don''t care anymore... > > Apologies - the silence is accidental not deliberate. > > Having the #ifdef in console_force_unlock() would be a substantially > smaller and safer backport with the same effect.So I''ll do it that way then. Jan