preparations for 4.13.1 and 4.12.3

preparations for 4.13.1 and 4.12.3

[Jan Beulich]

All,

the releases are due in a week or two. Please point out backports
you find missing from the respective staging branches, but which
you consider relevant. (Ian, I notice there haven't been any
tools side backports at all so far. Julien, Stefano - same for
Arm.)

Jan

Re: preparations for 4.13.1 and 4.12.3

[Jürgen Groß]

On 09.04.20 09:41, Jan Beulich wrote:
> All,
> 
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)
> 
> Jan
> 

Commit bb2a34fd740e9a26be9e2244f1a5b4cef439e5a8 should be backported
to both IMO (tools patch).


Juergen

Re: preparations for 4.13.1 and 4.12.3

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On Thu, Apr 09, 2020 at 09:41:49AM +0200, Jan Beulich wrote:
> All,
> 
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)

Proposed backports (tools):

0d99c909d7 libxl: wait for console path before firing console_available
d094e95fb7 libxl: fix cleanup bug in initiate_domain_create()
1f706eace3 libxl: create domain 'error' node in xenstore
e19b4b3b55 tools/python: mismatch between pyxc_methods flags and PyObject definitions
1430c5a8ca tools/python: Python 3 compatibility

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: preparations for 4.13.1 and 4.12.3

[Julien Grall]

Hi,

On 09/04/2020 08:52, Jürgen Groß wrote:
> On 09.04.20 09:41, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a week or two. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, I notice there haven't been any
>> tools side backports at all so far. Julien, Stefano - same for
>> Arm.)
>>
>> Jan
>>
> 
> Commit bb2a34fd740e9a26be9e2244f1a5b4cef439e5a8 should be backported
> to both IMO (tools patch).

I was going to suggest this one as well :).

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.1 and 4.12.3

[Julien Grall]

On 09/04/2020 08:41, Jan Beulich wrote:
> All,

Hi Jan & Stefano,

> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)

Below a list of suggested backport for Arm for 4.12 and 4.13:

b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a  xen/arm: initialize vpl011 
flag register
b31666c8912bf18d9eff963b06d856e7e818ff34  xen/arm: during efi boot, 
improve the check for usable memory
f14f55b7ee295277c8dd09e37e0fa0902ccf7eb4  xen/arm: remove physical timer 
offset
3c601c5f056fba055b7a1438b84b69fc649275c3  xen/arm: Sign extend 
TimerValue when computing the CompareValue

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.1 and 4.12.3

[Stefano Stabellini]

On Fri, 10 Apr 2020, Julien Grall wrote:
> On 09/04/2020 08:41, Jan Beulich wrote:
> > All,
> 
> Hi Jan & Stefano,
> 
> > the releases are due in a week or two. Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant. (Ian, I notice there haven't been any
> > tools side backports at all so far. Julien, Stefano - same for
> > Arm.)
> 
> Below a list of suggested backport for Arm for 4.12 and 4.13:
> 
> b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a  xen/arm: initialize vpl011 flag
> register
> b31666c8912bf18d9eff963b06d856e7e818ff34  xen/arm: during efi boot, improve
> the check for usable memory
> f14f55b7ee295277c8dd09e37e0fa0902ccf7eb4  xen/arm: remove physical timer
> offset
> 3c601c5f056fba055b7a1438b84b69fc649275c3  xen/arm: Sign extend TimerValue when
> computing the CompareValue


Thanks! I did these four and also the following:

69da7d5440c609c57c5bba9a73b91c62ba2852e6 xen/arm: Handle unimplemented VGICv3 registers as RAZ/WI



Jan,

I think the following could be a good candidate. It also touches x86 so
I thought I should ask you.

6827bea2b3b99153821b8b7446bdced27f720188 dom0-build: fix build with clang5

Re: preparations for 4.13.1 and 4.12.3

[Julien Grall]

Hi Stefano,

On 10/04/2020 17:37, Stefano Stabellini wrote:
> On Fri, 10 Apr 2020, Julien Grall wrote:
>> On 09/04/2020 08:41, Jan Beulich wrote:
>>> All,
>>
>> Hi Jan & Stefano,
>>
>>> the releases are due in a week or two. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant. (Ian, I notice there haven't been any
>>> tools side backports at all so far. Julien, Stefano - same for
>>> Arm.)
>>
>> Below a list of suggested backport for Arm for 4.12 and 4.13:
>>
>> b4637ed6cd5375f04ac51d6b900a9ccad6c6c03a  xen/arm: initialize vpl011 flag
>> register
>> b31666c8912bf18d9eff963b06d856e7e818ff34  xen/arm: during efi boot, improve
>> the check for usable memory
>> f14f55b7ee295277c8dd09e37e0fa0902ccf7eb4  xen/arm: remove physical timer
>> offset
>> 3c601c5f056fba055b7a1438b84b69fc649275c3  xen/arm: Sign extend TimerValue when
>> computing the CompareValue
> 
> 
> Thanks! I did these four and also the following:
> 
> 69da7d5440c609c57c5bba9a73b91c62ba2852e6 xen/arm: Handle unimplemented VGICv3 registers as RAZ/WI

I saw it and forgot to add it in the list :$.

> 
> 
> 
> Jan,
> 
> I think the following could be a good candidate. It also touches x86 so
> I thought I should ask you.
> 
> 6827bea2b3b99153821b8b7446bdced27f720188 dom0-build: fix build with clang5

If we are backporting build fixes for newer compilers, shouldn't we 
backport all of them?

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.1 and 4.12.3

[Jan Beulich]

On 10.04.2020 19:54, Julien Grall wrote:
> On 10/04/2020 17:37, Stefano Stabellini wrote:
>> I think the following could be a good candidate. It also touches x86 so
>> I thought I should ask you.
>>
>> 6827bea2b3b99153821b8b7446bdced27f720188 dom0-build: fix build with clang5

Hmm, I didn't think anyone but me had noticed the issue, or else
I would have expected some support in getting this in faster than
it actually went in (half a yer? more?), so I had rather decided
against.

> If we are backporting build fixes for newer compilers, shouldn't we backport all of them?

Probably; I'm not sure I'd call clang5 "newer" though. Aren't they
at v9 or v10 now? Irrespective of this - are you aware of other
"newer compiler" changes? Normally I would pick such up, at the
very least for the newest of the stable trees, but generally for
all of them since sooner or later we'd be hit by people trying to
build older (by the time) trees with new tool chains.

Jan

Re: preparations for 4.13.1 and 4.12.3

[Andrew Cooper]

On 09/04/2020 08:41, Jan Beulich wrote:
> All,
>
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)

540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
which fixes crashes after vcpu hotplug in shim.

It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
53594c7bd197 which are other RCU bugfixes.

~Andrew

Re: preparations for 4.13.1 and 4.12.3

[Jan Beulich]

On 14.04.2020 15:07, Andrew Cooper wrote:
> On 09/04/2020 08:41, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a week or two. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, I notice there haven't been any
>> tools side backports at all so far. Julien, Stefano - same for
>> Arm.)
> 
> 540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
> which fixes crashes after vcpu hotplug in shim.
> 
> It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
> 53594c7bd197 which are other RCU bugfixes.

And cef21210fb133 as well as a6fe79a5979a then. Iirc we had even
talked about this on irc, and were largely in agreement that this
is a little beyond what we'd normally backport.

I have to admit that while I followed Igor's advice that there is
a dependency of his patch on Jürgen's work, I'm still not really
clear where that dependency actually lies. The patch merely moves
where rcu_barrier() gets invoked from (thus covering previously
uncovered places). If there hadn't been that named dependency, I
would have taken Igor's patch already.

Jan

Re: preparations for 4.13.1 and 4.12.3

[Igor Druzhinin]

On 14/04/2020 14:36, Jan Beulich wrote:
> On 14.04.2020 15:07, Andrew Cooper wrote:
>> On 09/04/2020 08:41, Jan Beulich wrote:
>>> All,
>>>
>>> the releases are due in a week or two. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant. (Ian, I notice there haven't been any
>>> tools side backports at all so far. Julien, Stefano - same for
>>> Arm.)
>>
>> 540d4d60378c "cpu: sync any remaining RCU callbacks before CPU up/down"
>> which fixes crashes after vcpu hotplug in shim.
>>
>> It looks to depend on 53ddfc80a84a, a9b6dacf88fe, c301211a5111 and
>> 53594c7bd197 which are other RCU bugfixes.
> 
> And cef21210fb133 as well as a6fe79a5979a then. Iirc we had even
> talked about this on irc, and were largely in agreement that this
> is a little beyond what we'd normally backport.

Correct. Those 2 could be taken for completeness but not strictly necessary.
On the other hand, those mentioned by Andrew (maybe except for a9b6dacf88fe)
are necessary prerequisites.

> I have to admit that while I followed Igor's advice that there is
> a dependency of his patch on Jürgen's work, I'm still not really
> clear where that dependency actually lies. The patch merely moves
> where rcu_barrier() gets invoked from (thus covering previously
> uncovered places). If there hadn't been that named dependency, I
> would have taken Igor's patch already.

There is dependency in the fact after my patch is applied - rcu_barrier gets
invoked very frequently unlike before. This uncovers many issues in its
implementation that are addressed by RCU series. Without RCU series
rcu_barrier call is unstable and causes race condition induced crashes and
is incompatible with core-scheduling.

Igor

Re: preparations for 4.13.1 and 4.12.3

[Sander Eikelenboom]

On 09/04/2020 09:41, Jan Beulich wrote:
> All,
> 
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefano - same for
> Arm.)
> 
> Jan

I would like to suggest for 4.13.1:

4b5b431edd984b26f43b3efc7de465f3560a949e "tools/xentop: Fix calculation
of used memory"

Thanks,

--
Sander