preparations for 4.13.2 and 4.12.4

preparations for 4.13.2 and 4.12.4

[Jan Beulich]

All,

the releases are about due, but will of course want to wait for the
XSA fixes going public on the 22nd. Please point out backports
you find missing from the respective staging branches, but which
you consider relevant. (Ian, Julien, Stefano: I notice there once
again haven't been any tools or Arm side backports at all so far
since the most recent stable releases from these branches. But
maybe there simply aren't any.)

One that I have queued already, but which first need to at least
pass the push gate to master, are

8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
b4e41b1750d5 b4e41b1750d5 [4.14 only]

On the Arm side I'd also like to ask for

5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers

Jan

Re: preparations for 4.13.2 and 4.12.4

[Bertrand Marquis]

> On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
> 
> All,
> 
> the releases are about due, but will of course want to wait for the
> XSA fixes going public on the 22nd. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, Julien, Stefano: I notice there once
> again haven't been any tools or Arm side backports at all so far
> since the most recent stable releases from these branches. But
> maybe there simply aren't any.)
> 
> One that I have queued already, but which first need to at least
> pass the push gate to master, are
> 
> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
> b4e41b1750d5 b4e41b1750d5 [4.14 only]
> 
> On the Arm side I'd also like to ask for
> 
> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers
+1

Could those fixes also be considered:
3b418b3326 arm: Add Neoverse N1 processor identification
858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT erratum
968bb86d04 xen/arm: Missing N1/A76/A75 FP registers in vCPU context switch
f4c1a541fa xen/arm: Throw messages for unknown FP/SIMD implement ID

Those are erratas and bug fixes.

Bertrand

Re: preparations for 4.13.2 and 4.12.4

[Jan Beulich]

On 11.09.2020 15:32, Bertrand Marquis wrote:
> 
> 
>> On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> All,
>>
>> the releases are about due, but will of course want to wait for the
>> XSA fixes going public on the 22nd. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, Julien, Stefano: I notice there once
>> again haven't been any tools or Arm side backports at all so far
>> since the most recent stable releases from these branches. But
>> maybe there simply aren't any.)
>>
>> One that I have queued already, but which first need to at least
>> pass the push gate to master, are
>>
>> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
>> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
>> b4e41b1750d5 b4e41b1750d5 [4.14 only]
>>
>> On the Arm side I'd also like to ask for
>>
>> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers
> +1
> 
> Could those fixes also be considered:
> 3b418b3326 arm: Add Neoverse N1 processor identification
> 858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
> 1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT erratum
> 968bb86d04 xen/arm: Missing N1/A76/A75 FP registers in vCPU context switch
> f4c1a541fa xen/arm: Throw messages for unknown FP/SIMD implement ID
> 
> Those are erratas and bug fixes.

Well, that's for Julien and/or Stefano then.

Jan

Re: preparations for 4.13.2 and 4.12.4

[Julien Grall]

Hi Bertrand,

On 11/09/2020 14:32, Bertrand Marquis wrote:
>> On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
>>
>> All,
>>
>> the releases are about due, but will of course want to wait for the
>> XSA fixes going public on the 22nd. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, Julien, Stefano: I notice there once
>> again haven't been any tools or Arm side backports at all so far
>> since the most recent stable releases from these branches. But
>> maybe there simply aren't any.)
>>
>> One that I have queued already, but which first need to at least
>> pass the push gate to master, are
>>
>> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
>> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
>> b4e41b1750d5 b4e41b1750d5 [4.14 only]
>>
>> On the Arm side I'd also like to ask for
>>
>> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers
> +1
> 
> Could those fixes also be considered:
> 3b418b3326 arm: Add Neoverse N1 processor identification
> 858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
> 1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT erratum
The processor is quite new so may I ask why we would want to backport on 
older Xen?

> 968bb86d04 xen/arm: Missing N1/A76/A75 FP registers in vCPU context switch

I would consider this one because 4.12 as already errata for A76, so it 
is meant to work with it.

> f4c1a541fa xen/arm: Throw messages for unknown FP/SIMD implement ID

This is technically not a bug fix and there are many ways for older Xen 
to not work on newer/recent processors. So I wouldn't consider this as a 
backport.

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.2 and 4.12.4

[Bertrand Marquis]

> On 11 Sep 2020, at 14:51, Julien Grall <julien@xen.org> wrote:
> 
> Hi Bertrand,
> 
> On 11/09/2020 14:32, Bertrand Marquis wrote:
>>> On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
>>> 
>>> All,
>>> 
>>> the releases are about due, but will of course want to wait for the
>>> XSA fixes going public on the 22nd. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider relevant. (Ian, Julien, Stefano: I notice there once
>>> again haven't been any tools or Arm side backports at all so far
>>> since the most recent stable releases from these branches. But
>>> maybe there simply aren't any.)
>>> 
>>> One that I have queued already, but which first need to at least
>>> pass the push gate to master, are
>>> 
>>> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
>>> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
>>> b4e41b1750d5 b4e41b1750d5 [4.14 only]
>>> 
>>> On the Arm side I'd also like to ask for
>>> 
>>> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers
>> +1
>> Could those fixes also be considered:
>> 3b418b3326 arm: Add Neoverse N1 processor identification
>> 858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
>> 1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT erratum
> The processor is quite new so may I ask why we would want to backport on older Xen?

4.14 at least would be good as it is the current stable and N1SDP is support in Yocto which is based on 4.14.
Older versions where because the BSP in Yocto was initially done on Dunfell Yocto release which was based on 4.12.
But as the official one will be on next Yocto release this would be ok to consider only 4.14 here.

> 
>> 968bb86d04 xen/arm: Missing N1/A76/A75 FP registers in vCPU context switch
> 
> I would consider this one because 4.12 as already errata for A76, so it is meant to work with it.
> 
>> f4c1a541fa xen/arm: Throw messages for unknown FP/SIMD implement ID
> 
> This is technically not a bug fix and there are many ways for older Xen to not work on newer/recent processors. So I wouldn't consider this as a backport.

Ok.

Bertrand

> Cheers,
> 
> -- 
> Julien Grall

Re: preparations for 4.13.2 and 4.12.4

[Julien Grall]

Hi Bertrand,

On 11/09/2020 14:56, Bertrand Marquis wrote:
> 
> 
>> On 11 Sep 2020, at 14:51, Julien Grall <julien@xen.org> wrote:
>>
>> Hi Bertrand,
>>
>> On 11/09/2020 14:32, Bertrand Marquis wrote:
>>>> On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> All,
>>>>
>>>> the releases are about due, but will of course want to wait for the
>>>> XSA fixes going public on the 22nd. Please point out backports
>>>> you find missing from the respective staging branches, but which
>>>> you consider relevant. (Ian, Julien, Stefano: I notice there once
>>>> again haven't been any tools or Arm side backports at all so far
>>>> since the most recent stable releases from these branches. But
>>>> maybe there simply aren't any.)
>>>>
>>>> One that I have queued already, but which first need to at least
>>>> pass the push gate to master, are
>>>>
>>>> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
>>>> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
>>>> b4e41b1750d5 b4e41b1750d5 [4.14 only]
>>>>
>>>> On the Arm side I'd also like to ask for
>>>>
>>>> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers
>>> +1
>>> Could those fixes also be considered:
>>> 3b418b3326 arm: Add Neoverse N1 processor identification
>>> 858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
>>> 1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT erratum
>> The processor is quite new so may I ask why we would want to backport on older Xen?
> 
> 4.14 at least would be good as it is the current stable and N1SDP is support in Yocto which is based on 4.14.
While I understand external project are often based on stable release, I 
don't want to always backport errata. Some of them are quite involved 
and this is a risk for others.

In this case, the erratum has already been implemented for other 
processors. So the risk is minimal.

> But as the official one will be on next Yocto release this would be ok to consider only 4.14 here.

4.14 only would be my preference.

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.2 and 4.12.4

[Julien Grall]

On 11/09/2020 14:11, Jan Beulich wrote:
> All,
> 
> the releases are about due, but will of course want to wait for the
> XSA fixes going public on the 22nd. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, Julien, Stefano: I notice there once
> again haven't been any tools or Arm side backports at all so far
> since the most recent stable releases from these branches. But
> maybe there simply aren't any.)
> 
> One that I have queued already, but which first need to at least
> pass the push gate to master, are
> 
> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
> b4e41b1750d5 b4e41b1750d5 [4.14 only]
> 
> On the Arm side I'd also like to ask for
> 
> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers

Sounds good to me.

I would also add:

d501ef90ae7f xen/arm: cmpxchg: Add missing memory barriers in 
__cmpxchg_mb_timeout() [4.12+]

Cheers,

-- 
Julien Grall

Re: preparations for 4.13.2 and 4.12.4

[Bertrand Marquis]

> On 11 Sep 2020, at 15:25, Julien Grall <julien@xen.org> wrote:
> 
> Hi Bertrand,
> 
> On 11/09/2020 14:56, Bertrand Marquis wrote:
>>> On 11 Sep 2020, at 14:51, Julien Grall <julien@xen.org> wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On 11/09/2020 14:32, Bertrand Marquis wrote:
>>>>> On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> 
>>>>> All,
>>>>> 
>>>>> the releases are about due, but will of course want to wait for the
>>>>> XSA fixes going public on the 22nd. Please point out backports
>>>>> you find missing from the respective staging branches, but which
>>>>> you consider relevant. (Ian, Julien, Stefano: I notice there once
>>>>> again haven't been any tools or Arm side backports at all so far
>>>>> since the most recent stable releases from these branches. But
>>>>> maybe there simply aren't any.)
>>>>> 
>>>>> One that I have queued already, but which first need to at least
>>>>> pass the push gate to master, are
>>>>> 
>>>>> 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
>>>>> e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
>>>>> b4e41b1750d5 b4e41b1750d5 [4.14 only]
>>>>> 
>>>>> On the Arm side I'd also like to ask for
>>>>> 
>>>>> 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics helpers
>>>> +1
>>>> Could those fixes also be considered:
>>>> 3b418b3326 arm: Add Neoverse N1 processor identification
>>>> 858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
>>>> 1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT erratum
>>> The processor is quite new so may I ask why we would want to backport on older Xen?
>> 4.14 at least would be good as it is the current stable and N1SDP is support in Yocto which is based on 4.14.
> While I understand external project are often based on stable release, I don't want to always backport errata. Some of them are quite involved and this is a risk for others.
> 
> In this case, the erratum has already been implemented for other processors. So the risk is minimal.
> 
>> But as the official one will be on next Yocto release this would be ok to consider only 4.14 here.
> 
> 4.14 only would be my preference.

This is ok for me if we have all those only in 4.14 (errata and FP/SIMD).

Cheers
Bertrand

Re: preparations for 4.13.2 and 4.12.4

[Stefano Stabellini]

On Fri, 11 Sep 2020, Julien Grall wrote:
> Hi Bertrand,
> 
> On 11/09/2020 14:56, Bertrand Marquis wrote:
> > 
> > 
> > > On 11 Sep 2020, at 14:51, Julien Grall <julien@xen.org> wrote:
> > > 
> > > Hi Bertrand,
> > > 
> > > On 11/09/2020 14:32, Bertrand Marquis wrote:
> > > > > On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@suse.com> wrote:
> > > > > 
> > > > > All,
> > > > > 
> > > > > the releases are about due, but will of course want to wait for the
> > > > > XSA fixes going public on the 22nd. Please point out backports
> > > > > you find missing from the respective staging branches, but which
> > > > > you consider relevant. (Ian, Julien, Stefano: I notice there once
> > > > > again haven't been any tools or Arm side backports at all so far
> > > > > since the most recent stable releases from these branches. But
> > > > > maybe there simply aren't any.)
> > > > > 
> > > > > One that I have queued already, but which first need to at least
> > > > > pass the push gate to master, are
> > > > > 
> > > > > 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in
> > > > > e820
> > > > > e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
> > > > > b4e41b1750d5 b4e41b1750d5 [4.14 only]
> > > > > 
> > > > > On the Arm side I'd also like to ask for
> > > > > 
> > > > > 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics
> > > > > helpers
> > > > +1
> > > > Could those fixes also be considered:
> > > > 3b418b3326 arm: Add Neoverse N1 processor identification
> > > > 858c0be8c2 xen/arm: Enable CPU Erratum 1165522 for Neoverse
> > > > 1814a626fb xen/arm: Update silicon-errata.txt with the Neovers AT
> > > > erratum
> > > The processor is quite new so may I ask why we would want to backport on
> > > older Xen?
> > 
> > 4.14 at least would be good as it is the current stable and N1SDP is support
> > in Yocto which is based on 4.14.
> While I understand external project are often based on stable release, I don't
> want to always backport errata. Some of them are quite involved and this is a
> risk for others.

Yeah, I very much agree with this. Some of them are **very** involved,
we don't really want to backport them. Speaking of which, maybe we
should add some wording to SUPPORT.md about it? Currently it doesn't
say anything specific about errata.


> In this case, the erratum has already been implemented for other processors.
> So the risk is minimal.
> 
> > But as the official one will be on next Yocto release this would be ok to
> > consider only 4.14 here.
> 
> 4.14 only would be my preference.

These ones are so trivial that apply straight away to all trees. I
understand it is not your preference, but I'll backport them up until
4.12 unless you are strongly opposed to it.

Re: preparations for 4.13.2 and 4.12.4

[Stefano Stabellini]

On Fri, 11 Sep 2020, Julien Grall wrote:
> On 11/09/2020 14:11, Jan Beulich wrote:
> > All,
> > 
> > the releases are about due, but will of course want to wait for the
> > XSA fixes going public on the 22nd. Please point out backports
> > you find missing from the respective staging branches, but which
> > you consider relevant. (Ian, Julien, Stefano: I notice there once
> > again haven't been any tools or Arm side backports at all so far
> > since the most recent stable releases from these branches. But
> > maybe there simply aren't any.)
> > 
> > One that I have queued already, but which first need to at least
> > pass the push gate to master, are
> > 
> > 8efa46516c5f hvmloader: indicate ACPI tables with "ACPI data" type in e820
> > e5a1b6f0d207 x86/mm: do not mark IO regions as Xen heap
> > b4e41b1750d5 b4e41b1750d5 [4.14 only]
> > 
> > On the Arm side I'd also like to ask for
> > 
> > 5d45ecabe3c0 xen/arm64: force gcc 10+ to always inline generic atomics
> > helpers
> 
> Sounds good to me.
> 
> I would also add:
> 
> d501ef90ae7f xen/arm: cmpxchg: Add missing memory barriers in
> __cmpxchg_mb_timeout() [4.12+]

OK