Re: [Xen-devel] [qemu-upstream-4.11-testing test] 136184: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.06.19 at 11:57, <julien.grall@xxxxxxx> wrote:

> 
> On 6/4/19 10:17 AM, Jan Beulich wrote:
>>>>> On 04.06.19 at 11:01, <julien.grall@xxxxxxx> wrote:
>>> On 6/4/19 8:06 AM, Jan Beulich wrote:
>>>>>>> On 03.06.19 at 19:15, <anthony.perard@xxxxxxxxxx> wrote:
>>>>> It turns out that the first commit that fails to boot on rochester is
>>>>>     e202feb713 xen/cmdline: Fix buggy strncmp(s, LITERAL, ss - s) 
>>>>> construct
>>>>> (even with the "eb8acba82a xen: Fix backport of .." applied)
>>>>
>>>> Now that's particularly odd a regression candidate. It doesn't
>>>> touch any Arm code at all (nor does the fixup commit). And the
>>>> common code changes don't look "risky" either; the one thing that
>>>> jumps out as the most likely of all the unlikely candidates would
>>>> seem to be the xen/common/efi/boot.c change, but if there was
>>>> a problem there then the EFI boot on Arm would be latently
>>>> broken in other ways as well. Plus, of course, you say that the
>>>> same change is no problem on 4.12.
>>>>
>>>> Of course the commit itself could be further "bisected" - all
>>>> changes other than the introduction of cmdline_strcmp() are
>>>> completely independent of one another.
>>>
>>> I think this is just a red-herring. The commit is probably modifying
>>> enough the layout of Xen that TLB conflict will appear.
>>>
>>> Anthony said backporting 00c96d7742 "xen/arm: mm: Set-up page permission
>>> for Xen mappings earlier on" makes staging-4.11 boots. This patch
>>> removes some of the potential cause of TLB conflict.
>>>
>>> I haven't suggested a backport of this patch so far, because there are
>>> still TLB conflict possible within the function modified. It might also
>>> be possible that it exposes more of TLB conflict as more work in Xen is
>>> needed (see my MM-PARTn series).
>>>
>>> I don't know whether backporting this patch is worth it compare to the
>>> risk it introduces.
>> 
>> Well, if you don't backport this, what's the alternative road towards a
>> solution here? I'm afraid the two of you will need to decide one way or
>> another.
> 
> The "two" being?

You and Stefano, as was reflected by the To: list of my earlier reply.

Jan



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