Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Jan Beulich]

All,

with the goal of releasing by the end of next week (with little of no
further changes) - please test!

Thanks, Jan

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Andrew Cooper]

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, Jan

Looking 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

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Ian Jackson]

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.

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Andrew Cooper]

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

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Ian Jackson]

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.

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Ian Campbell]

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.

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1229 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 1914 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Jan Beulich]

>>> 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

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Ian Jackson]

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.

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Lars Kurth]

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.

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Jan Beulich]

>>> 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

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Jan Beulich]

>>> 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

Re: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged

[Jan Beulich]

>>> 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

Ping: backport proposals (was: Xen 4.2.3-rc2 and 4.1.6-rc2 have been tagged)

[Jan Beulich]

>>> 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

Re: Ping: backport proposals

[Andrew Cooper]

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

Re: Ping: backport proposals

[Jan Beulich]

>>> 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

Re: Ping: backport proposals

[Jan Beulich]

>>> 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