Re: preparations for 4.13.2 and 4.12.4

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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@xxxxxxx> wrote:
> > > 
> > > Hi Bertrand,
> > > 
> > > On 11/09/2020 14:32, Bertrand Marquis wrote:
> > > > > On 11 Sep 2020, at 14:11, Jan Beulich <jbeulich@xxxxxxxx> 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.