preparations for 4.11.2

preparations for 4.11.2

[Jan Beulich]

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

Jan



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

Re: preparations for 4.11.2

[Andrew Cooper]

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.

~Andrew

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

Re: [Xen-devel] preparations for 4.11.2

[Andrew Cooper]

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.

~Andrew

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

Re: preparations for 4.11.2

[Andrew Cooper]

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.

~Andrew

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

Re: [Xen-devel] preparations for 4.11.2

[Andrew Cooper]

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.

~Andrew

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

Re: preparations for 4.11.2

[Andrew Cooper]

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.

~Andrew

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

Re: [Xen-devel] preparations for 4.11.2

[Andrew Cooper]

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.

~Andrew

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

Re: preparations for 4.11.2

[Jan Beulich]

>>> On 16.05.19 at 17:11, <andrew.cooper3@citrix.com> 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.

Jan



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

Re: [Xen-devel] preparations for 4.11.2

[Jan Beulich]

>>> On 16.05.19 at 17:11, <andrew.cooper3@citrix.com> 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.

Jan



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

Re: preparations for 4.11.2

[Andrew Cooper]

On 16/05/2019 16:20, Jan Beulich wrote:
>>>> On 16.05.19 at 17:11, <andrew.cooper3@citrix.com> 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.

~Andrew

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

Re: [Xen-devel] preparations for 4.11.2

[Andrew Cooper]

On 16/05/2019 16:20, Jan Beulich wrote:
>>>> On 16.05.19 at 17:11, <andrew.cooper3@citrix.com> 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.

~Andrew

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

Re: preparations for 4.11.2

[Jan Beulich]

>>> On 16.05.19 at 17:23, <andrew.cooper3@citrix.com> wrote:
> On 16/05/2019 16:20, Jan Beulich wrote:
>>>>> On 16.05.19 at 17:11, <andrew.cooper3@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] preparations for 4.11.2

[Jan Beulich]

>>> On 16.05.19 at 17:23, <andrew.cooper3@citrix.com> wrote:
> On 16/05/2019 16:20, Jan Beulich wrote:
>>>>> On 16.05.19 at 17:11, <andrew.cooper3@citrix.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: preparations for 4.11.2

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] preparations for 4.11.2"):
> 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.

I'm sorry to throw a spanner in the works but at the very least

  tools/ocaml: Dup2 /dev/null to stdin in daemonize()

fixes quite an alarming bug.  And Andy is making a case for the SMT
fixes.

Currently I have these (not yet pushed):

989a2ec4f3ba tools/xl: use libxl_domain_info to get domain type for vcpu-pin
b55ff4c879ac tools/libxl: correct vcpu affinity output with sparse physical cpu map
4b72470175a5 tools/ocaml: Dup2 /dev/null to stdin in daemonize()
5c6be595b1bc tools/misc/xenpm: fix getting info when some CPUs are offline

Andy also mentioned this:

> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
> different featureset lengths"

which I think may be important but I asked a question about it.


Sorry, but I think it may be best to wait.  I'm open to being
persuaded...

Regards,
Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] preparations for 4.11.2"):
> 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.

I'm sorry to throw a spanner in the works but at the very least

  tools/ocaml: Dup2 /dev/null to stdin in daemonize()

fixes quite an alarming bug.  And Andy is making a case for the SMT
fixes.

Currently I have these (not yet pushed):

989a2ec4f3ba tools/xl: use libxl_domain_info to get domain type for vcpu-pin
b55ff4c879ac tools/libxl: correct vcpu affinity output with sparse physical cpu map
4b72470175a5 tools/ocaml: Dup2 /dev/null to stdin in daemonize()
5c6be595b1bc tools/misc/xenpm: fix getting info when some CPUs are offline

Andy also mentioned this:

> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
> different featureset lengths"

which I think may be important but I asked a question about it.


Sorry, but I think it may be best to wait.  I'm open to being
persuaded...

Regards,
Ian.

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

Re: preparations for 4.11.2

[Jan Beulich]

>>> On 16.05.19 at 18:21, <ian.jackson@citrix.com> wrote:
> Sorry, but I think it may be best to wait.  I'm open to being
> persuaded...

Okay - as also indicated on irc, with the weekend in between and
with the most recent flight having failed anyway it shouldn't be
too much of an extra delay. Yet to be honest - most or all of these
should have been requested and committed several weeks ago,
soon after the mail at the root of this thread was sent. I wonder
if I need to add a hard cut-off date to these initiator mails that I
send. I'd prefer not to, not the least because of unforeseen
issues like the recent month-long (or more?) osstest stall.

Jan



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

Re: [Xen-devel] preparations for 4.11.2

[Jan Beulich]

>>> On 16.05.19 at 18:21, <ian.jackson@citrix.com> wrote:
> Sorry, but I think it may be best to wait.  I'm open to being
> persuaded...

Okay - as also indicated on irc, with the weekend in between and
with the most recent flight having failed anyway it shouldn't be
too much of an extra delay. Yet to be honest - most or all of these
should have been requested and committed several weeks ago,
soon after the mail at the root of this thread was sent. I wonder
if I need to add a hard cut-off date to these initiator mails that I
send. I'd prefer not to, not the least because of unforeseen
issues like the recent month-long (or more?) osstest stall.

Jan



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

Re: preparations for 4.11.2

[Ian Jackson]

Jan Beulich writes ("Re: preparations for 4.11.2"):
> Okay - as also indicated on irc, with the weekend in between and
> with the most recent flight having failed anyway it shouldn't be
> too much of an extra delay.

Right.  OK, I have pushed my queue now.

> Yet to be honest - most or all of these
> should have been requested and committed several weeks ago,
> soon after the mail at the root of this thread was sent. I wonder
> if I need to add a hard cut-off date to these initiator mails that I
> send. I'd prefer not to, not the least because of unforeseen
> issues like the recent month-long (or more?) osstest stall.

I think stating a cut-off date would be a very sensible idea.  If
circumstances change you can always say "because of X, this deadline
is being waived/extended".

Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Jan Beulich writes ("Re: preparations for 4.11.2"):
> Okay - as also indicated on irc, with the weekend in between and
> with the most recent flight having failed anyway it shouldn't be
> too much of an extra delay.

Right.  OK, I have pushed my queue now.

> Yet to be honest - most or all of these
> should have been requested and committed several weeks ago,
> soon after the mail at the root of this thread was sent. I wonder
> if I need to add a hard cut-off date to these initiator mails that I
> send. I'd prefer not to, not the least because of unforeseen
> issues like the recent month-long (or more?) osstest stall.

I think stating a cut-off date would be a very sensible idea.  If
circumstances change you can always say "because of X, this deadline
is being waived/extended".

Ian.

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

Re: preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> In addition,

Thanks.

==== wanting discussion: ====

> 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.

We would be bumping the minor version.  I think it is ABI compatible.
So I am inclined to backport this one but I haven't done so yet.

> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> domain introduction"

Can you justify how this is a bugfix ?  It doesn't seem like backport
material to me.

> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
> syscalls"

This *really* doesn't look like a bugfix, let alone a backport
candidate !  Removing a lock for performance reasons !

> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
> different featureset lengths"

The compatibility implications here are not clearly spelled out in the
commit message.  AFAICT, after this commit, the effect is:
  - new tools will work with old hypervisor
  - old tools will not necessariloy work with old hypervisor
I assume that we are talking here about old and new code with the same
Xen version, eg as a result of a security fix.

The previous behaviour, ie, what happens without this patch, is not
entirely clear to me.

> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"

This might break some callers, mightn't it ?  What callers ?  Or is
there an argument that there aren't callers which will be broken ?


==== done: ====

> 2ec5339ec921 "tools/libxl: correct vcpu affinity output with sparse
> physical cpu map"

Backported to 4.11 and 4.10.


> 48dab9767d2e "tools/xl: use libxl_domain_info to get domain type for
> vcpu-pin"

Backported to 4.12, 4.11, 4.10.

Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> In addition,

Thanks.

==== wanting discussion: ====

> 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.

We would be bumping the minor version.  I think it is ABI compatible.
So I am inclined to backport this one but I haven't done so yet.

> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> domain introduction"

Can you justify how this is a bugfix ?  It doesn't seem like backport
material to me.

> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
> syscalls"

This *really* doesn't look like a bugfix, let alone a backport
candidate !  Removing a lock for performance reasons !

> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
> different featureset lengths"

The compatibility implications here are not clearly spelled out in the
commit message.  AFAICT, after this commit, the effect is:
  - new tools will work with old hypervisor
  - old tools will not necessariloy work with old hypervisor
I assume that we are talking here about old and new code with the same
Xen version, eg as a result of a security fix.

The previous behaviour, ie, what happens without this patch, is not
entirely clear to me.

> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"

This might break some callers, mightn't it ?  What callers ?  Or is
there an argument that there aren't callers which will be broken ?


==== done: ====

> 2ec5339ec921 "tools/libxl: correct vcpu affinity output with sparse
> physical cpu map"

Backported to 4.11 and 4.10.


> 48dab9767d2e "tools/xl: use libxl_domain_info to get domain type for
> vcpu-pin"

Backported to 4.12, 4.11, 4.10.

Ian.

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

Re: preparations for 4.11.2

[Andrew Cooper]

On 16/05/2019 17:17, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
>> In addition,
> Thanks.
>
> ==== wanting discussion: ====
>
>> 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.
> We would be bumping the minor version.  I think it is ABI compatible.
> So I am inclined to backport this one but I haven't done so yet.
>
>> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
>> domain introduction"
> Can you justify how this is a bugfix ?  It doesn't seem like backport
> material to me.

It was found from strace (while investigating an unrelated issue), but
given how many issues we've had in the past with {o,}xenstored exceeding
its FD limit, I'd still put it in the category of bugfix.

It balloons the worst-case FD requirements by as many concurrent domain
starts as the rest of dom0 can manage.

>
>> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
>> syscalls"
> This *really* doesn't look like a bugfix, let alone a backport
> candidate !  Removing a lock for performance reasons !

Of course its a backport candidate, and it is a bugfix even if most of
the time it is only observed as a perf improvement.

The Ocaml FFI says "thou shalt not make a syscall holding this lock",
because while that lock is held, everything is single threaded.

IIRC, this particular issue lead to a partial outage of one of our HTTP
API endpoints.

>
>> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
>> different featureset lengths"
> The compatibility implications here are not clearly spelled out in the
> commit message.  AFAICT, after this commit, the effect is:
>   - new tools will work with old hypervisor
>   - old tools will not necessariloy work with old hypervisor
> I assume that we are talking here about old and new code with the same
> Xen version, eg as a result of a security fix.
>
> The previous behaviour, ie, what happens without this patch, is not
> entirely clear to me.

This was an unintended consequence of XSA-253 (Spectre/Meltdown) where
the length of the featureset did increase in a security fix.

In the period of time between installing updated dom0 userspace
packages, and rebooting into the new hypervisor, attempting to start a
guest results in libc heap corruption and an abort().

Because libxl doesn't used the partially-improved CPUID functionality
yet, it doesn't hit the second bug of incoming migrates getting
intermittently rejected due to 4/8 bytes of heap metadata being included
in the CPUID safety check.

>> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"
> This might break some callers, mightn't it ?  What callers ?  Or is
> there an argument that there aren't callers which will be broken ?

This was from the same bit of debugging as above, and ISTR caused some
error messages in higher callers to print junk instead of the real error.

~Andrew

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

Re: [Xen-devel] preparations for 4.11.2

[Andrew Cooper]

On 16/05/2019 17:17, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
>> In addition,
> Thanks.
>
> ==== wanting discussion: ====
>
>> 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.
> We would be bumping the minor version.  I think it is ABI compatible.
> So I am inclined to backport this one but I haven't done so yet.
>
>> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
>> domain introduction"
> Can you justify how this is a bugfix ?  It doesn't seem like backport
> material to me.

It was found from strace (while investigating an unrelated issue), but
given how many issues we've had in the past with {o,}xenstored exceeding
its FD limit, I'd still put it in the category of bugfix.

It balloons the worst-case FD requirements by as many concurrent domain
starts as the rest of dom0 can manage.

>
>> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
>> syscalls"
> This *really* doesn't look like a bugfix, let alone a backport
> candidate !  Removing a lock for performance reasons !

Of course its a backport candidate, and it is a bugfix even if most of
the time it is only observed as a perf improvement.

The Ocaml FFI says "thou shalt not make a syscall holding this lock",
because while that lock is held, everything is single threaded.

IIRC, this particular issue lead to a partial outage of one of our HTTP
API endpoints.

>
>> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
>> different featureset lengths"
> The compatibility implications here are not clearly spelled out in the
> commit message.  AFAICT, after this commit, the effect is:
>   - new tools will work with old hypervisor
>   - old tools will not necessariloy work with old hypervisor
> I assume that we are talking here about old and new code with the same
> Xen version, eg as a result of a security fix.
>
> The previous behaviour, ie, what happens without this patch, is not
> entirely clear to me.

This was an unintended consequence of XSA-253 (Spectre/Meltdown) where
the length of the featureset did increase in a security fix.

In the period of time between installing updated dom0 userspace
packages, and rebooting into the new hypervisor, attempting to start a
guest results in libc heap corruption and an abort().

Because libxl doesn't used the partially-improved CPUID functionality
yet, it doesn't hit the second bug of incoming migrates getting
intermittently rejected due to 4/8 bytes of heap metadata being included
in the CPUID safety check.

>> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"
> This might break some callers, mightn't it ?  What callers ?  Or is
> there an argument that there aren't callers which will be broken ?

This was from the same bit of debugging as above, and ISTR caused some
error messages in higher callers to print junk instead of the real error.

~Andrew

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

Re: preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> On 16/05/2019 17:17, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> >> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> >> domain introduction"
> > Can you justify how this is a bugfix ?  It doesn't seem like backport
> > material to me.
> 
> It was found from strace (while investigating an unrelated issue), but
> given how many issues we've had in the past with {o,}xenstored exceeding
> its FD limit, I'd still put it in the category of bugfix.
> 
> It balloons the worst-case FD requirements by as many concurrent domain
> starts as the rest of dom0 can manage.

Thanks for the clarification.

> >> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
> >> syscalls"
> > This *really* doesn't look like a bugfix, let alone a backport
> > candidate !  Removing a lock for performance reasons !
> 
> Of course its a backport candidate, and it is a bugfix even if most of
> the time it is only observed as a perf improvement.
> 
> The Ocaml FFI says "thou shalt not make a syscall holding this lock",
> because while that lock is held, everything is single threaded.

That wasn't mentioned in the commit message, so I assumed that the
reason was the usual one for removing locks, namely simply to increase
cpu concurrency.

So these are bugfixes, but they're not particularly low risk based
just on the code.  How long has XS been running these patches ?  The
answer to that may give me some confidence that for users of Xen
stable branches, the possible reward of fixing a mysterious bad
behaviour is better to take the risk of these patches having bugs.

> >> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
> >> different featureset lengths"
> > The compatibility implications here are not clearly spelled out in the
> > commit message.  AFAICT, after this commit, the effect is:
> >   - new tools will work with old hypervisor
> >   - old tools will not necessariloy work with old hypervisor
> > I assume that we are talking here about old and new code with the same
> > Xen version, eg as a result of a security fix.
> >
> > The previous behaviour, ie, what happens without this patch, is not
> > entirely clear to me.
> 
> This was an unintended consequence of XSA-253 (Spectre/Meltdown) where
> the length of the featureset did increase in a security fix.

Cripes.

OK, so that is definitely wanted.  It applies cleanly back to 4.8, so
I have done that.  I guess it needs to be applied to 4.7 too ?  I get
conflicts.  Would you care to try to fix that up or shall I ?

> >> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"
> > This might break some callers, mightn't it ?  What callers ?  Or is
> > there an argument that there aren't callers which will be broken ?
> 
> This was from the same bit of debugging as above, and ISTR caused some
> error messages in higher callers to print junk instead of the real error.

Right.  I can see that that is annoying.  But given that the existing
behaviour is inconsistent, it is possible that *other* callers
somewhere are relying on the other behaviour and they may even check
errno values or something.  IOW you are changing the API of this
function from "omg what happens depends on what error it even was" to
something sane and uniform.

That is still an API change though, and maybe not sensible to
backport, if the only benefit is improved error messages.  It seems to
me this would depend on how likely it is that there are any callers
that would be broken by the change and in what situations that would
break.

Thanks for the info.

Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> On 16/05/2019 17:17, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> >> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> >> domain introduction"
> > Can you justify how this is a bugfix ?  It doesn't seem like backport
> > material to me.
> 
> It was found from strace (while investigating an unrelated issue), but
> given how many issues we've had in the past with {o,}xenstored exceeding
> its FD limit, I'd still put it in the category of bugfix.
> 
> It balloons the worst-case FD requirements by as many concurrent domain
> starts as the rest of dom0 can manage.

Thanks for the clarification.

> >> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
> >> syscalls"
> > This *really* doesn't look like a bugfix, let alone a backport
> > candidate !  Removing a lock for performance reasons !
> 
> Of course its a backport candidate, and it is a bugfix even if most of
> the time it is only observed as a perf improvement.
> 
> The Ocaml FFI says "thou shalt not make a syscall holding this lock",
> because while that lock is held, everything is single threaded.

That wasn't mentioned in the commit message, so I assumed that the
reason was the usual one for removing locks, namely simply to increase
cpu concurrency.

So these are bugfixes, but they're not particularly low risk based
just on the code.  How long has XS been running these patches ?  The
answer to that may give me some confidence that for users of Xen
stable branches, the possible reward of fixing a mysterious bad
behaviour is better to take the risk of these patches having bugs.

> >> c393b64dcee6 "tools/libxc: Fix issues with libxc and Xen having
> >> different featureset lengths"
> > The compatibility implications here are not clearly spelled out in the
> > commit message.  AFAICT, after this commit, the effect is:
> >   - new tools will work with old hypervisor
> >   - old tools will not necessariloy work with old hypervisor
> > I assume that we are talking here about old and new code with the same
> > Xen version, eg as a result of a security fix.
> >
> > The previous behaviour, ie, what happens without this patch, is not
> > entirely clear to me.
> 
> This was an unintended consequence of XSA-253 (Spectre/Meltdown) where
> the length of the featureset did increase in a security fix.

Cripes.

OK, so that is definitely wanted.  It applies cleanly back to 4.8, so
I have done that.  I guess it needs to be applied to 4.7 too ?  I get
conflicts.  Would you care to try to fix that up or shall I ?

> >> 82855aba5bf9 "tools/libxc: Fix error handling in get_cpuid_domain_info()"
> > This might break some callers, mightn't it ?  What callers ?  Or is
> > there an argument that there aren't callers which will be broken ?
> 
> This was from the same bit of debugging as above, and ISTR caused some
> error messages in higher callers to print junk instead of the real error.

Right.  I can see that that is annoying.  But given that the existing
behaviour is inconsistent, it is possible that *other* callers
somewhere are relying on the other behaviour and they may even check
errno values or something.  IOW you are changing the API of this
function from "omg what happens depends on what error it even was" to
something sane and uniform.

That is still an API change though, and maybe not sensible to
backport, if the only benefit is improved error messages.  It seems to
me this would depend on how likely it is that there are any callers
that would be broken by the change and in what situations that would
break.

Thanks for the info.

Ian.

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

Re: preparations for 4.11.2

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> > On 16/05/2019 17:17, Ian Jackson wrote:
> > > Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> > >> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> > >> domain introduction"
...
> > >> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
> > >> syscalls"
...
> So these are bugfixes, but they're not particularly low risk based
> just on the code.  How long has XS been running these patches ?  The
> answer to that may give me some confidence that for users of Xen
> stable branches, the possible reward of fixing a mysterious bad
> behaviour is better to take the risk of these patches having bugs.

Based on this:

12:17 <andyhhp> XS has been using those ocaml changes for longer than they've 
                been upstream
12:19 <andyhhp> although if you're still hesitant, it really isn't the end of 
                the world.  Your decision here doesn't affect XS - we've 
                already got them backported in the patchqueue

I have taken 129025fe3093 "oxenstored: Don't re-open a xenctrl
handle..." to 4.11 and 4.10.

7b20a865bc10 "tools/ocaml: Release the global lock..." does not apply
cleanly.  Do you happen to have a version for 4.11 and/or 4.10 ?  I am
not convinced I ought to try to fix the backport myself particularly
if Citrix XS have been running a textually different patch for a long
time...

The rest of this I think is still in question and IMO not a blocker
for 4.11.2.

Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> > On 16/05/2019 17:17, Ian Jackson wrote:
> > > Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> > >> 129025fe3093 "oxenstored: Don't re-open a xenctrl handle for every
> > >> domain introduction"
...
> > >> 7b20a865bc10 "tools/ocaml: Release the global lock before invoking block
> > >> syscalls"
...
> So these are bugfixes, but they're not particularly low risk based
> just on the code.  How long has XS been running these patches ?  The
> answer to that may give me some confidence that for users of Xen
> stable branches, the possible reward of fixing a mysterious bad
> behaviour is better to take the risk of these patches having bugs.

Based on this:

12:17 <andyhhp> XS has been using those ocaml changes for longer than they've 
                been upstream
12:19 <andyhhp> although if you're still hesitant, it really isn't the end of 
                the world.  Your decision here doesn't affect XS - we've 
                already got them backported in the patchqueue

I have taken 129025fe3093 "oxenstored: Don't re-open a xenctrl
handle..." to 4.11 and 4.10.

7b20a865bc10 "tools/ocaml: Release the global lock..." does not apply
cleanly.  Do you happen to have a version for 4.11 and/or 4.10 ?  I am
not convinced I ought to try to fix the backport myself particularly
if Citrix XS have been running a textually different patch for a long
time...

The rest of this I think is still in question and IMO not a blocker
for 4.11.2.

Ian.

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

Re: preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Oh, and 677e64dbe315343620c3b266e9eb16623b118038 "tools/ocaml: Dup2
> /dev/null to stdin in daemonize()" again for 4.12 and earlier.

This is already in 4.12.  It's quite alarming so I decided to backport
it all the way to 4.7 (last release in security support).

Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> Oh, and 677e64dbe315343620c3b266e9eb16623b118038 "tools/ocaml: Dup2
> /dev/null to stdin in daemonize()" again for 4.12 and earlier.

This is already in 4.12.  It's quite alarming so I decided to backport
it all the way to 4.7 (last release in security support).

Ian.

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

Re: preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> ffb60a58df48419c1f2607cd3cc919fa2bfc9c2d "tools/misc/xenpm: fix getting
> info when some CPUs are offline" for 4.11 and earlier.

Thanks, queued for 4.11 and 4.10.

Ian.

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

Re: [Xen-devel] preparations for 4.11.2

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] preparations for 4.11.2"):
> ffb60a58df48419c1f2607cd3cc919fa2bfc9c2d "tools/misc/xenpm: fix getting
> info when some CPUs are offline" for 4.11 and earlier.

Thanks, queued for 4.11 and 4.10.

Ian.

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