preparations for 4.16.1

preparations for 4.16.1

[Jan Beulich]

All,

the release is due in a few weeks time.

Please point out backports you find missing from the respective staging
branch, but which you consider relevant. One I have queued already, but
which I'd like to put in only once the pending fix to it ("x86: avoid
SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is

4b7fd8153ddf x86: fold sections in final binaries

Jan

Re: preparations for 4.16.1

[Jan Beulich]

On 10.03.2022 09:57, Jan Beulich wrote:
> Please point out backports you find missing from the respective staging
> branch, but which you consider relevant. One I have queued already, but
> which I'd like to put in only once the pending fix to it ("x86: avoid
> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
> 
> 4b7fd8153ddf x86: fold sections in final binaries

Actually the other one I'm aware of is

7d9589239ec0 x86/CET: Fix S3 resume with shadow stacks active

which Andrew promised to provide a suitable backport for.

Jan

Re: preparations for 4.16.1

[Andrew Cooper]

On 10/03/2022 09:01, Jan Beulich wrote:
> On 10.03.2022 09:57, Jan Beulich wrote:
>> Please point out backports you find missing from the respective staging
>> branch, but which you consider relevant. One I have queued already, but
>> which I'd like to put in only once the pending fix to it ("x86: avoid
>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>>
>> 4b7fd8153ddf x86: fold sections in final binaries
> Actually the other one I'm aware of is
>
> 7d9589239ec0 x86/CET: Fix S3 resume with shadow stacks active
>
> which Andrew promised to provide a suitable backport for.

So now XSA-398 is public, I can say what that slightly cryptically meant.

The CET S3 fix depends on one of the code rearrangements introduced in
the CET-IBT work.  We were intending to have CET-IBT backported for the
tuesday embargo (didn't go to plan), after which the S3 fix would be a
trivial backport to 4.14 and later.

~Andrew

Re: preparations for 4.16.1

[Jan Beulich]

On 10.03.2022 11:20, Andrew Cooper wrote:
> On 10/03/2022 09:01, Jan Beulich wrote:
>> On 10.03.2022 09:57, Jan Beulich wrote:
>>> Please point out backports you find missing from the respective staging
>>> branch, but which you consider relevant. One I have queued already, but
>>> which I'd like to put in only once the pending fix to it ("x86: avoid
>>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>>>
>>> 4b7fd8153ddf x86: fold sections in final binaries
>> Actually the other one I'm aware of is
>>
>> 7d9589239ec0 x86/CET: Fix S3 resume with shadow stacks active
>>
>> which Andrew promised to provide a suitable backport for.
> 
> So now XSA-398 is public, I can say what that slightly cryptically meant.
> 
> The CET S3 fix depends on one of the code rearrangements introduced in
> the CET-IBT work.  We were intending to have CET-IBT backported for the
> tuesday embargo (didn't go to plan), after which the S3 fix would be a
> trivial backport to 4.14 and later.

I was indeed wondering. Even if this didn't work out in time, aiui the
plan still is to have that backported (without going the manual annotation
route). Do you expect this to be feasible in time (and not at the last
minute) for 4.16.1?

Jan

Re: preparations for 4.16.1

[Andrew Cooper]

On 10/03/2022 10:35, Jan Beulich wrote:
> On 10.03.2022 11:20, Andrew Cooper wrote:
>> On 10/03/2022 09:01, Jan Beulich wrote:
>>> On 10.03.2022 09:57, Jan Beulich wrote:
>>>> Please point out backports you find missing from the respective staging
>>>> branch, but which you consider relevant. One I have queued already, but
>>>> which I'd like to put in only once the pending fix to it ("x86: avoid
>>>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>>>>
>>>> 4b7fd8153ddf x86: fold sections in final binaries
>>> Actually the other one I'm aware of is
>>>
>>> 7d9589239ec0 x86/CET: Fix S3 resume with shadow stacks active
>>>
>>> which Andrew promised to provide a suitable backport for.
>> So now XSA-398 is public, I can say what that slightly cryptically meant.
>>
>> The CET S3 fix depends on one of the code rearrangements introduced in
>> the CET-IBT work.  We were intending to have CET-IBT backported for the
>> tuesday embargo (didn't go to plan), after which the S3 fix would be a
>> trivial backport to 4.14 and later.
> I was indeed wondering. Even if this didn't work out in time, aiui the
> plan still is to have that backported (without going the manual annotation
> route). Do you expect this to be feasible in time (and not at the last
> minute) for 4.16.1?

The answer is largely dependent on how long it takes to resolve the
remaining issues on staging (although most are done now.  I'm sifting
through things for a commit sweep).

Early next week, assuming no additional fun is found?

~Andrew

Re: preparations for 4.16.1

[Jan Beulich]

On 10.03.2022 12:14, Andrew Cooper wrote:
> On 10/03/2022 10:35, Jan Beulich wrote:
>> On 10.03.2022 11:20, Andrew Cooper wrote:
>>> On 10/03/2022 09:01, Jan Beulich wrote:
>>>> On 10.03.2022 09:57, Jan Beulich wrote:
>>>>> Please point out backports you find missing from the respective staging
>>>>> branch, but which you consider relevant. One I have queued already, but
>>>>> which I'd like to put in only once the pending fix to it ("x86: avoid
>>>>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>>>>>
>>>>> 4b7fd8153ddf x86: fold sections in final binaries
>>>> Actually the other one I'm aware of is
>>>>
>>>> 7d9589239ec0 x86/CET: Fix S3 resume with shadow stacks active
>>>>
>>>> which Andrew promised to provide a suitable backport for.
>>> So now XSA-398 is public, I can say what that slightly cryptically meant.
>>>
>>> The CET S3 fix depends on one of the code rearrangements introduced in
>>> the CET-IBT work.  We were intending to have CET-IBT backported for the
>>> tuesday embargo (didn't go to plan), after which the S3 fix would be a
>>> trivial backport to 4.14 and later.
>> I was indeed wondering. Even if this didn't work out in time, aiui the
>> plan still is to have that backported (without going the manual annotation
>> route). Do you expect this to be feasible in time (and not at the last
>> minute) for 4.16.1?
> 
> The answer is largely dependent on how long it takes to resolve the
> remaining issues on staging (although most are done now.  I'm sifting
> through things for a commit sweep).
> 
> Early next week, assuming no additional fun is found?

Early next week would certainly be faster than what I was hoping for ...

Jan

Re: preparations for 4.16.1

[Julien Grall]

On 10/03/2022 08:57, Jan Beulich wrote:
> All,

Hi,

> the release is due in a few weeks time.
> 
> Please point out backports you find missing from the respective staging
> branch, but which you consider relevant. One I have queued already, but
> which I'd like to put in only once the pending fix to it ("x86: avoid
> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
> 
> 4b7fd8153ddf x86: fold sections in final binaries

For arm, I would like to propose backporting:

32365f3476: xen/arm64: Zero the top 32 bits of gp registers on entry...

Stefano, what do you think?

Cheers,

-- 
Julien Grall

Re: preparations for 4.16.1

[Bertrand Marquis]

Hi,


> On 10 Mar 2022, at 09:04, Julien Grall <julien@xen.org> wrote:
> 
> On 10/03/2022 08:57, Jan Beulich wrote:
>> All,
> 
> Hi,
> 
>> the release is due in a few weeks time.
>> Please point out backports you find missing from the respective staging
>> branch, but which you consider relevant. One I have queued already, but
>> which I'd like to put in only once the pending fix to it ("x86: avoid
>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>> 4b7fd8153ddf x86: fold sections in final binaries
> 
> For arm, I would like to propose backporting:
> 
> 32365f3476: xen/arm64: Zero the top 32 bits of gp registers on entry...
> 

Agree (not changing the fact that Stefano should confirm)

I would like the following one to also be considered:
f3999bc: arm/efi: Handle Xen bootargs from both xen.cfg and DT
f1f38e2: xen/arm: increase memory banks number define value

And maybe this doc fix:
620ed2c: docs/efi: Fix wrong compatible in dts example

Stefano and Julien could tell what you think ?

Cheers
Bertrand

> Stefano, what do you think?
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

Re: preparations for 4.16.1

[Bertrand Marquis]

> On 10 Mar 2022, at 10:02, Bertrand Marquis <Bertrand.Marquis@arm.com> wrote:
> 
> Hi,
> 
> 
>> On 10 Mar 2022, at 09:04, Julien Grall <julien@xen.org> wrote:
>> 
>> On 10/03/2022 08:57, Jan Beulich wrote:
>>> All,
>> 
>> Hi,
>> 
>>> the release is due in a few weeks time.
>>> Please point out backports you find missing from the respective staging
>>> branch, but which you consider relevant. One I have queued already, but
>>> which I'd like to put in only once the pending fix to it ("x86: avoid
>>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>>> 4b7fd8153ddf x86: fold sections in final binaries
>> 
>> For arm, I would like to propose backporting:
>> 
>> 32365f3476: xen/arm64: Zero the top 32 bits of gp registers on entry...
>> 
> 
> Agree (not changing the fact that Stefano should confirm)
> 
> I would like the following one to also be considered:
> f3999bc: arm/efi: Handle Xen bootargs from both xen.cfg and DT
> f1f38e2: xen/arm: increase memory banks number define value
> 
> And maybe this doc fix:
> 620ed2c: docs/efi: Fix wrong compatible in dts example

Sorry please ignore this one, already in :-)

> 
> Stefano and Julien could tell what you think ?
> 
> Cheers
> Bertrand
> 
>> Stefano, what do you think?
>> 
>> Cheers,
>> 
>> -- 
>> Julien Grall

Re: preparations for 4.16.1

[Julien Grall]

On 10/03/2022 10:02, Bertrand Marquis wrote:
> Hi,

Hi Bertrand,

>> On 10 Mar 2022, at 09:04, Julien Grall <julien@xen.org> wrote:
>> On 10/03/2022 08:57, Jan Beulich wrote:
>>> the release is due in a few weeks time.
>>> Please point out backports you find missing from the respective staging
>>> branch, but which you consider relevant. One I have queued already, but
>>> which I'd like to put in only once the pending fix to it ("x86: avoid
>>> SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
>>> 4b7fd8153ddf x86: fold sections in final binaries
>>
>> For arm, I would like to propose backporting:
>>
>> 32365f3476: xen/arm64: Zero the top 32 bits of gp registers on entry...
>>
> 
> Agree (not changing the fact that Stefano should confirm)
> 
> I would like the following one to also be considered:
> f3999bc: arm/efi: Handle Xen bootargs from both xen.cfg and DT
> f1f38e2: xen/arm: increase memory banks number define value

I am fine with both.

Cheers,

-- 
Julien Grall

Re: preparations for 4.16.1

[Stefano Stabellini]

On Thu, 10 Mar 2022, Julien Grall wrote:
> On 10/03/2022 10:02, Bertrand Marquis wrote:
> > Hi,
> > > On 10 Mar 2022, at 09:04, Julien Grall <julien@xen.org> wrote:
> > > On 10/03/2022 08:57, Jan Beulich wrote:
> > > > the release is due in a few weeks time.
> > > > Please point out backports you find missing from the respective staging
> > > > branch, but which you consider relevant. One I have queued already, but
> > > > which I'd like to put in only once the pending fix to it ("x86: avoid
> > > > SORT_BY_INIT_PRIORITY with old GNU ld") has also landed in staging, is
> > > > 4b7fd8153ddf x86: fold sections in final binaries
> > > 
> > > For arm, I would like to propose backporting:
> > > 
> > > 32365f3476: xen/arm64: Zero the top 32 bits of gp registers on entry...
> > > 
> > 
> > Agree (not changing the fact that Stefano should confirm)
> > 
> > I would like the following one to also be considered:
> > f3999bc: arm/efi: Handle Xen bootargs from both xen.cfg and DT
> > f1f38e2: xen/arm: increase memory banks number define value
> 
> I am fine with both.

Agree and done