Hi all,
Today's linux-next merge of the hyperv tree got a conflict in:
arch/x86/include/asm/mshyperv.h
between commit:
a0e2bf7cb700 ("x86/paravirt: Switch time pvops functions to use static_call()")
from the tip tree and commit:
eb3e1d370b4c ("clocksource/drivers/hyper-v: Handle sched_clock differences inline")
from the hyperv tree.
I fixed it up (I used the latter version of this file and then applied the
following patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
From: Stephen Rothwell <[email protected]>
Date: Mon, 15 Mar 2021 14:31:07 +1100
Subject: [PATCH] fix up for "x86/paravirt: Switch time pvops functions to use
static_call()"
Signed-off-by: Stephen Rothwell <[email protected]>
---
drivers/clocksource/hyperv_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
index ce94f78eb851..1348afc6efbf 100644
--- a/drivers/clocksource/hyperv_timer.c
+++ b/drivers/clocksource/hyperv_timer.c
@@ -490,7 +490,7 @@ static __always_inline void hv_setup_sched_clock(void *sched_clock)
static __always_inline void hv_setup_sched_clock(void *sched_clock)
{
/* We're on x86/x64 *and* using PV ops */
- pv_ops.time.sched_clock = sched_clock;
+ paravirt_set_sched_clock(sched_clock);
}
#else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
static __always_inline void hv_setup_sched_clock(void *sched_clock) {}
--
2.30.0
--
Cheers,
Stephen Rothwell
From: Stephen Rothwell <[email protected]> Sent: Sunday, March 14, 2021 8:35 PM
>
> Hi all,
>
> Today's linux-next merge of the hyperv tree got a conflict in:
>
> arch/x86/include/asm/mshyperv.h
>
> between commit:
>
> a0e2bf7cb700 ("x86/paravirt: Switch time pvops functions to use static_call()")
>
> from the tip tree and commit:
>
> eb3e1d370b4c ("clocksource/drivers/hyper-v: Handle sched_clock differences inline")
>
> from the hyperv tree.
>
> I fixed it up (I used the latter version of this file and then applied the
> following patch) and can carry the fix as necessary. This is now fixed
> as far as linux-next is concerned, but any non trivial conflicts should
> be mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
>
> From: Stephen Rothwell <[email protected]>
> Date: Mon, 15 Mar 2021 14:31:07 +1100
> Subject: [PATCH] fix up for "x86/paravirt: Switch time pvops functions to use
> static_call()"
>
> Signed-off-by: Stephen Rothwell <[email protected]>
> ---
> drivers/clocksource/hyperv_timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c
> index ce94f78eb851..1348afc6efbf 100644
> --- a/drivers/clocksource/hyperv_timer.c
> +++ b/drivers/clocksource/hyperv_timer.c
> @@ -490,7 +490,7 @@ static __always_inline void hv_setup_sched_clock(void
> *sched_clock)
> static __always_inline void hv_setup_sched_clock(void *sched_clock)
> {
> /* We're on x86/x64 *and* using PV ops */
> - pv_ops.time.sched_clock = sched_clock;
> + paravirt_set_sched_clock(sched_clock);
> }
> #else /* !CONFIG_GENERIC_SCHED_CLOCK && !CONFIG_PARAVIRT */
> static __always_inline void hv_setup_sched_clock(void *sched_clock) {}
> --
> 2.30.0
>
> --
> Cheers,
> Stephen Rothwell
Thanks. That's the correct fix for the conflict.
Michael
On Mon, Mar 15, 2021 at 02:35:05PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the hyperv tree got a conflict in:
>
> arch/x86/include/asm/mshyperv.h
>
> between commit:
>
> a0e2bf7cb700 ("x86/paravirt: Switch time pvops functions to use static_call()")
>
> from the tip tree and commit:
>
> eb3e1d370b4c ("clocksource/drivers/hyper-v: Handle sched_clock differences inline")
>
> from the hyperv tree.
>
> I fixed it up (I used the latter version of this file and then applied the
> following patch) and can carry the fix as necessary. This is now fixed
> as far as linux-next is concerned, but any non trivial conflicts should
> be mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
Right,
so tglx and I took a quick look and came to the conclusion that it would
be best if you - provided it is not too much trouble - keep applying
this patch so that linux-next can get tested properly and we - Wei or I
- explain this merge conflict in our pull requests during the next merge
window and ask Linus to merge your patch ontop. This way we'll save us
the cross-tree merging dance.
Thx!
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
On Tue, Mar 16, 2021 at 04:02:54PM +0100, Borislav Petkov wrote:
> On Mon, Mar 15, 2021 at 02:35:05PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the hyperv tree got a conflict in:
> >
> > arch/x86/include/asm/mshyperv.h
> >
> > between commit:
> >
> > a0e2bf7cb700 ("x86/paravirt: Switch time pvops functions to use static_call()")
> >
> > from the tip tree and commit:
> >
> > eb3e1d370b4c ("clocksource/drivers/hyper-v: Handle sched_clock differences inline")
> >
> > from the hyperv tree.
> >
> > I fixed it up (I used the latter version of this file and then applied the
> > following patch) and can carry the fix as necessary. This is now fixed
> > as far as linux-next is concerned, but any non trivial conflicts should
> > be mentioned to your upstream maintainer when your tree is submitted for
> > merging. You may also want to consider cooperating with the maintainer
> > of the conflicting tree to minimise any particularly complex conflicts.
>
> Right,
>
> so tglx and I took a quick look and came to the conclusion that it would
> be best if you - provided it is not too much trouble - keep applying
> this patch so that linux-next can get tested properly and we - Wei or I
> - explain this merge conflict in our pull requests during the next merge
> window and ask Linus to merge your patch ontop. This way we'll save us
> the cross-tree merging dance.
Totally agreed. :-)
I've made a note to inform Linus about this in the next merge window.
Thanks,
Wei.
>
> Thx!
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Software Solutions Germany GmbH, GF: Felix Imend?rffer, HRB 36809, AG N?rnberg
Hi all,
On Tue, 16 Mar 2021 15:05:54 +0000 Wei Liu <[email protected]> wrote:
>
> > Right,
> >
> > so tglx and I took a quick look and came to the conclusion that it would
> > be best if you - provided it is not too much trouble - keep applying
> > this patch so that linux-next can get tested properly and we - Wei or I
> > - explain this merge conflict in our pull requests during the next merge
> > window and ask Linus to merge your patch ontop. This way we'll save us
> > the cross-tree merging dance.
>
> Totally agreed. :-)
>
> I've made a note to inform Linus about this in the next merge window.
No worries, I will keep applying the patch (my setup allows that to
happen automatically). Linus should apply it as a part of the merge
resolution (as do I).
--
Cheers,
Stephen Rothwell
On Wed, Mar 17, 2021 at 08:07:44AM +1100, Stephen Rothwell wrote:
> No worries, I will keep applying the patch (my setup allows that to
> happen automatically). Linus should apply it as a part of the merge
> resolution (as do I).
Thanks!
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg