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 <[email protected]> wrote: > > > > > > Hi Bertrand, > > > > > > On 11/09/2020 14:32, Bertrand Marquis wrote: > > > > > On 11 Sep 2020, at 14:11, Jan Beulich <[email protected]> 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.
