Re: [Xen-devel] preparations for 4.11.2

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.05.19 at 17:23, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/05/2019 16:20, Jan Beulich wrote:
>>>>> On 16.05.19 at 17:11, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 26/04/2019 13:02, Andrew Cooper wrote:
>>>> On 26/04/2019 12:59, Andrew Cooper wrote:
>>>>> On 18/03/2019 16:13, Jan Beulich wrote:
>>>>>> All,
>>>>>>
>>>>>> the release is due by the end of the month, but will likely don't make
>>>>>> it before early April. Please point out backports you find missing from
>>>>>> the respective staging branch, but which you consider relevant. The
>>>>>> one commit I've queued already on top of what was just pushed is
>>>>>>
>>>>>> 22e2f8dddf       x86/e820: fix build with gcc9
>>>>> ffb60a58df48419c1f2607cd3cc919fa2bfc9c2d "tools/misc/xenpm: fix getting
>>>>> info when some CPUs are offline" for 4.11 and earlier.
>>>> Oh, and 677e64dbe315343620c3b266e9eb16623b118038 "tools/ocaml: Dup2
>>>> /dev/null to stdin in daemonize()" again for 4.12 and earlier.
>>> In addition,
>>>
>>> 2ec5339ec921 "tools/libxl: correct vcpu affinity output with sparse
>>> physical cpu map"
>>> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
>>> domain introduction"
>>> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
>>> syscalls"
>>> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
>>> different featureset lengths"
>>> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"
>>> 48dab9767d2e "tools/xl: use libxl_domain_info to get domain type for
>>> vcpu-pin"
>>>
>>> 365aabb6e502 "tools/libxendevicemodel: add
>>> xendevicemodel_modified_memory_bulk to map" is possibly a candidate, but
>>> is also complicated by the stable SONAME.  It is perhaps easiest to
>>> ignore, seeing as the issue has already gone unnoticed for 2 years.
>> Unless these are really urgent to put in, I'd like them to be deferred
>> to 4.11.3. With XSA-297 out we've already started the (leaf tree)
>> tagging process, so I was really hoping to get this much delayed
>> release out rather sooner than later.
> 
> At a minimum, ffb60a58df4 and ffb60a58df4 need backporting, because they
> are breakage of tools caused by our recommendation to turn off SMT in
> recent XSAs.
> 
> Everything else can be deferred if necessary.

Well, it's mostly an all or nothing thing: If another osstest flight is
going to be needed anyway, then perhaps the full set could still
be put in. But we're already late by 1.5 months...

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel