[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26fb88f9-dd20-c56b-e87d-6d454b4f7c71@suse.com>
Date: Wed, 29 Mar 2017 11:28:13 +0200
From: Juergen Gross <jgross@...e.com>
To: Ingo Molnar <mingo@...nel.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Xen Devel <Xen-devel@...ts.xensource.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Mathias Krause <minipli@...glemail.com>,
Thomas Garnier <thgarnie@...gle.com>
Subject: Re: linux-next: manual merge of the xen-tip tree with the tip tree
On 29/03/17 10:59, Ingo Molnar wrote:
>
> * Juergen Gross <jgross@...e.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.
Juergen
Powered by blists - more mailing lists