Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1611540 > unrolled thread

linux-next: manual merge of the xen-tip tree with the tip tree

Back to article view | Back to linux.kernel

Contents

  linux-next: manual merge of the xen-tip tree with the tip tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-03-29 05:40 +0200
    Re: linux-next: manual merge of the xen-tip tree with the tip tree Juergen Gross <jgross@suse.com> - 2017-03-29 10:40 +0200
      Re: linux-next: manual merge of the xen-tip tree with the tip tree Ingo Molnar <mingo@kernel.org> - 2017-03-29 11:10 +0200
        Re: linux-next: manual merge of the xen-tip tree with the tip tree Juergen Gross <jgross@suse.com> - 2017-03-29 11:30 +0200
          Re: linux-next: manual merge of the xen-tip tree with the tip tree Vitaly Kuznetsov <vkuznets@redhat.com> - 2017-03-29 12:10 +0200
          Re: linux-next: manual merge of the xen-tip tree with the tip tree Ingo Molnar <mingo@kernel.org> - 2017-04-03 16:40 +0200
            Re: linux-next: manual merge of the xen-tip tree with the tip tree Juergen Gross <jgross@suse.com> - 2017-04-03 17:20 +0200
        Re: linux-next: manual merge of the xen-tip tree with the tip tree Juergen Gross <jgross@suse.com> - 2017-03-29 12:00 +0200
          Re: linux-next: manual merge of the xen-tip tree with the tip tree Ingo Molnar <mingo@kernel.org> - 2017-03-29 12:50 +0200
          Re: linux-next: manual merge of the xen-tip tree with the tip tree Stephen Rothwell <sfr@canb.auug.org.au> - 2017-03-29 13:20 +0200

#1611540 — linux-next: manual merge of the xen-tip tree with the tip tree

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.
-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1611690

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.

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.

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.

Thoughts?


Juergen

[toc] | [prev] | [next] | [standalone]

#1611712

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

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1611724

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.


Juergen

[toc] | [prev] | [next] | [standalone]

#1611773

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

[toc] | [prev] | [next] | [standalone]

#1615264

* Juergen Gross <jgross@suse.com> wrote:

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

I've created a tip:x86-mm-for-xen branch with the following head:

  7f75540ff2ca ("Merge tag 'v4.11-rc5' into x86/mm, to refresh the branch")

... which should be a reasonable base that includes a working version of the 
5-level pagetable changes.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1615319

On 03/04/17 16:38, Ingo Molnar wrote:
> 
> * Juergen Gross <jgross@suse.com> wrote:
> 
>>> 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.
> 
> I've created a tip:x86-mm-for-xen branch with the following head:
> 
>   7f75540ff2ca ("Merge tag 'v4.11-rc5' into x86/mm, to refresh the branch")
> 
> ... which should be a reasonable base that includes a working version of the 
> 5-level pagetable changes.

Thanks,


Juergen

[toc] | [prev] | [next] | [standalone]

#1611769

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.

Stephen, I have rewound the linux-next branch of xen-tip to its previous
position. You can re-enable xen-tip.


Juergen

[toc] | [prev] | [next] | [standalone]

#1611813

* Juergen Gross <jgross@suse.com> wrote:

> 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.
> 
> Stephen, I have rewound the linux-next branch of xen-tip to its previous
> position. You can re-enable xen-tip.

Thank you!

	Ingo

[toc] | [prev] | [next] | [standalone]

#1611830

Hi Juergen,

On Wed, 29 Mar 2017 11:54:57 +0200 Juergen Gross <jgross@suse.com> wrote:
>
> Stephen, I have rewound the linux-next branch of xen-tip to its previous
> position. You can re-enable xen-tip.

Thanks, it should be all good tomorrow.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web