On 16/07/18 16:26, Jan Beulich wrote:
On 16.07.18 at 16:21, wrote:
>> So maybe changing the condition in cpupool_cpu_add() should be split out
>> into a patch of its own in order to be able to backport it?
>
> We'll want/need to backport this change anyway.
Okay, so even if its a bugfix on
>>> On 16.07.18 at 16:21, wrote:
> So maybe changing the condition in cpupool_cpu_add() should be split out
> into a patch of its own in order to be able to backport it?
We'll want/need to backport this change anyway.
Jan
___
Xen-devel mailing list
On 16/07/18 15:01, Jan Beulich wrote:
On 16.07.18 at 14:47, wrote:
>> On 16/07/18 14:19, Jan Beulich wrote:
>> On 16.07.18 at 13:47, wrote:
On 16/07/18 11:17, Jan Beulich wrote:
On 13.07.18 at 11:02, wrote:
>> On 11/07/18 14:04, Jan Beulich wrote:
>>> While I've
On 16/07/18 14:19, Jan Beulich wrote:
On 16.07.18 at 13:47, wrote:
>> On 16/07/18 11:17, Jan Beulich wrote:
>> On 13.07.18 at 11:02, wrote:
On 11/07/18 14:04, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the
>>> On 16.07.18 at 13:47, wrote:
> On 16/07/18 11:17, Jan Beulich wrote:
> On 13.07.18 at 11:02, wrote:
>>> On 11/07/18 14:04, Jan Beulich wrote:
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
On 11/07/18 14:04, Jan Beulich wrote:
> While I've run into the issue with further patches in place which no
> longer guarantee the per-CPU area to start out as all zeros, the
> CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
> the per-CPU cpupool pointer,
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
of
