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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: linux-next: manual merge of the hyperv tree with the tip tree

[Michael Kelley]

From: Stephen Rothwell <sfr@canb.auug.org.au> 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 <sfr@canb.auug.org.au>
> 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 <sfr@canb.auug.org.au>
> ---
>  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

Re: linux-next: manual merge of the hyperv tree with the tip tree

[Borislav Petkov]

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

Re: linux-next: manual merge of the hyperv tree with the tip tree

[Wei Liu]

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

Re: linux-next: manual merge of the hyperv tree with the tip tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Hi all,

On Tue, 16 Mar 2021 15:05:54 +0000 Wei Liu <wei.liu@kernel.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the hyperv tree with the tip tree

[Borislav Petkov]

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

Re: linux-next: manual merge of the hyperv tree with the tip tree

[Wei Liu]

On Tue, Oct 26, 2021 at 10:27:26AM +0200, Borislav Petkov wrote:
> On Tue, Oct 26, 2021 at 05:22:51PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the hyperv tree got a conflict in:
> > 
> >   arch/x86/mm/pat/set_memory.c
> > 
> > between commit:
> > 
> >   e9d1d2bb75b2 ("treewide: Replace the use of mem_encrypt_active() with cc_platform_has()")
> > 
> > from the tip tree and commit:
> > 
> >   cf90c4532b92 ("x86/hyperv: Add new hvcall guest address host visibility support")
> > 
> > from the hyperv tree.
> > 
> > I fixed it up (see below) 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.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc arch/x86/mm/pat/set_memory.c
> > index 527957586f3c,525f682ab150..000000000000
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@@ -2024,6 -2025,17 +2026,17 @@@ static int __set_memory_enc_pgtable(uns
> >   	return ret;
> >   }
> >   
> > + static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> > + {
> > + 	if (hv_is_isolation_supported())
> > + 		return hv_set_mem_host_visibility(addr, numpages, !enc);
> > + 
> >  -	if (mem_encrypt_active())
> > ++	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> > + 		return __set_memory_enc_pgtable(addr, numpages, enc);
> > + 
> > + 	return 0;
> > + }
> > + 
> >   int set_memory_encrypted(unsigned long addr, int numpages)
> >   {
> >   	return __set_memory_enc_dec(addr, numpages, true);
> 
> Looks good, thanks.
> 
> Wei, you could mention this conflict when sending to Linus or you can
> simply merge into your branch the tip branch tip:x86/cc which has the
> cc_platform_has() changes and then redo the isolation VM stuff ontop.
> 

Boris and Stephen, thanks for the heads-up.

Wei.

> HTH.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

Re: linux-next: manual merge of the hyperv tree with the tip tree

[Borislav Petkov]

On Tue, Oct 26, 2021 at 05:22:51PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the hyperv tree got a conflict in:
> 
>   arch/x86/mm/pat/set_memory.c
> 
> between commit:
> 
>   e9d1d2bb75b2 ("treewide: Replace the use of mem_encrypt_active() with cc_platform_has()")
> 
> from the tip tree and commit:
> 
>   cf90c4532b92 ("x86/hyperv: Add new hvcall guest address host visibility support")
> 
> from the hyperv tree.
> 
> I fixed it up (see below) 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/mm/pat/set_memory.c
> index 527957586f3c,525f682ab150..000000000000
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@@ -2024,6 -2025,17 +2026,17 @@@ static int __set_memory_enc_pgtable(uns
>   	return ret;
>   }
>   
> + static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> + {
> + 	if (hv_is_isolation_supported())
> + 		return hv_set_mem_host_visibility(addr, numpages, !enc);
> + 
>  -	if (mem_encrypt_active())
> ++	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
> + 		return __set_memory_enc_pgtable(addr, numpages, enc);
> + 
> + 	return 0;
> + }
> + 
>   int set_memory_encrypted(unsigned long addr, int numpages)
>   {
>   	return __set_memory_enc_dec(addr, numpages, true);

Looks good, thanks.

Wei, you could mention this conflict when sending to Linus or you can
simply merge into your branch the tip branch tip:x86/cc which has the
cc_platform_has() changes and then redo the isolation VM stuff ontop.

HTH.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

Hi all,

Today's linux-next merge of the hyperv tree got a conflict in:

  arch/x86/mm/pat/set_memory.c

between commit:

  e9d1d2bb75b2 ("treewide: Replace the use of mem_encrypt_active() with cc_platform_has()")

from the tip tree and commit:

  cf90c4532b92 ("x86/hyperv: Add new hvcall guest address host visibility support")

from the hyperv tree.

I fixed it up (see below) 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/mm/pat/set_memory.c
index 527957586f3c,525f682ab150..000000000000
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@@ -2024,6 -2025,17 +2026,17 @@@ static int __set_memory_enc_pgtable(uns
  	return ret;
  }
  
+ static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
+ {
+ 	if (hv_is_isolation_supported())
+ 		return hv_set_mem_host_visibility(addr, numpages, !enc);
+ 
 -	if (mem_encrypt_active())
++	if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
+ 		return __set_memory_enc_pgtable(addr, numpages, enc);
+ 
+ 	return 0;
+ }
+ 
  int set_memory_encrypted(unsigned long addr, int numpages)
  {
  	return __set_memory_enc_dec(addr, numpages, true);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

Hi all,

Today's linux-next merge of the hyperv tree got a conflict in:

  arch/x86/hyperv/hv_init.c

between commit:

  c43426334b31 ("x86: Fix leftover comment typos")

from the tip tree and commit:

  a4d7e8ae4a54 ("Drivers: hv: Move Hyper-V extended capability check to arch neutral code")

from the hyperv tree.

I fixed it up (the comment changed by the former commit was move so I
applied the following merge fix 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 <sfr@canb.auug.org.au>
Date: Mon, 21 Jun 2021 19:56:59 +1000
Subject: [PATCH] x86: move of part of "Fix leftover comment typos"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/hv/hv_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index f0053c786891..7f42da98d377 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -27,7 +27,7 @@ bool hv_query_ext_cap(u64 cap_query)
 	 * output parameter to the hypercall below and so it should be
 	 * compatible with 'virt_to_phys'. Which means, it's address should be
 	 * directly mapped. Use 'static' to keep it compatible; stack variables
-	 * can be virtually mapped, making them imcompatible with
+	 * can be virtually mapped, making them incompatible with
 	 * 'virt_to_phys'.
 	 * Hypercall input/output addresses should also be 8-byte aligned.
 	 */
-- 
2.30.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]