lkml.org 
[lkml]   [2017]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: linux-next: manual merge of the xen-tip tree with the tip tree
Date
Juergen Gross <jgross@suse.com> writes:

> On 29/03/17 10:59, Ingo Molnar wrote:
>>
>> * Juergen Gross <jgross@suse.com> wrote:
>>
>>> On 29/03/17 05:35, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Today's linux-next merge of the xen-tip tree got a conflict in:
>>>>
>>>> arch/x86/xen/enlighten.c
>>>>
>>>> between commits:
>>>>
>>>> 6415813bae75 ("x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86")
>>>> 69218e47994d ("x86: Remap GDT tables in the fixmap section")
>>>> b23adb7d3f7d ("x86/xen/gdt: Use X86_FEATURE_XENPV instead of globals for the GDT fixup")
>>>>
>>>> from the tip tree and commits:
>>>>
>>>> 75cd32d6093e ("x86/xen: split off enlighten_pv.c")
>>>>
>>>> from the xen-tip tree.
>>>>
>>>> I dropped the xen-tip tree for today (see other conflict reports),
>>>> please get together and sort these out, thanks.
>>>>
>>>
>>> Hmm, seems to be a rather bad timing for the series of Vitaly.
>>>
>>> What is the best way to resolve those conflicts? A rebase of Vitaly's
>>> patches seems to be required in any case.
>>>
>>> Should I rebase the Xen tree on current tip? This seems to be rather
>>> easy, but I think this will work only if I can be sure the current tip
>>> tree contents will all be merged by Linus before the Xen tree.
>>
>> That's certainly very likely, -tip trees all go in very early in the merge window.
>>
>>> I could try to cherry pick the patches from tip where Vitaly's patches
>>> have conflicts with, but I think this could lead to a lot of patches
>>> to take.
>>
>> Nor is it desirable as a workflow.
>>
>> I'd suggest the following: in about a week I can guarantee a working tip:x86/mm
>> base with most of the 5-level paging patches applied that you could base Xen
>> patches on.
>>
>> Unfortunately, right now there's at least one regression with those changes that
>> needs to be properly fixed before it's a suitable base tree. The fix already
>> exists, it just needs to be tested and the whole tree needs to cook for a few days
>> to be dependable for Xen as a base.
>>
>>> Or we could delay Vitaly's series until tip has been merged, but this
>>> will either delay some other Xen patches depending on (or conflicting
>>> with) Vitaly's patches or would make the rebase for Vitaly more
>>> difficult.
>>
>> So my suggestion would be: could you delay 75cd32d6093e for a week, and then merge
>> it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on the first day
>> of the merge window so there shouldn't be any ordering problems.
>
> Okay, that's rather easy to do.
>
> Boris, I renamed the current Xen for-linus-4.12 branch for easy
> development of other Xen patches to for-linus-4.12-pre.
>
> I'll create another branch for-linus-4.12 based on the tip tree next
> week which will be subject to the pull request for Linus. As soon as
> for-linus-4.12 is ready the for-linus-4.12-pre branch shouldn't be used
> any longer.

Please let me know if/when I need to rebase my series. I'll rebase, test
and re-send.

Thanks!

--
Vitaly

\
 
 \ /
  Last update: 2017-03-29 12:07    [W:0.075 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site