linux-next: manual merge of the kvms390 tree with the s390 tree

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

Hi all,

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

  arch/s390/include/asm/facilities_src.h

between commit:

  d1f7e8f85b51 ("s390: squash facilities_src.h into gen_facilities.c")

from the s390 tree and commits:

  09ff894457e9 ("KVM: s390: gaccess: add ESOP2 handling")
  88abf0b54f51 ("KVM: s390: instruction-execution-protection support")

from the kvms390 tree.

I fixed it up (I deleted the file and then added 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: Wed, 23 Nov 2016 14:41:34 +1100
Subject: [PATCH] KVM: s390: merge fix for squashing of facilities_src.h into
 gen_facilities.c

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/s390/tools/gen_facilities.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 8cc53b1e6d03..0cf802de52a1 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -80,6 +80,8 @@ static struct facility_def facility_defs[] = {
 			76, /* msa extension 3 */
 			77, /* msa extension 4 */
 			78, /* enhanced-DAT 2 */
+			130, /* instruction-execution-protection */
+			131, /* enhanced-SOP 2 and side-effect */
 			-1  /* END */
 		}
 	},
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Christian Borntraeger]

On 11/23/2016 04:45 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   arch/s390/include/asm/facilities_src.h
> 
> between commit:
> 
>   d1f7e8f85b51 ("s390: squash facilities_src.h into gen_facilities.c")
> 
> from the s390 tree and commits:
> 
>   09ff894457e9 ("KVM: s390: gaccess: add ESOP2 handling")
>   88abf0b54f51 ("KVM: s390: instruction-execution-protection support")
> 
> from the kvms390 tree.
> 
> I fixed it up (I deleted the file and then added 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.

Thanks, looks fine.

Hmmm, Martin, Heiko, KVM is going to touch that file from time to time.
Can we either have 
a: a topic branch for this tool (like I did for the 4.9 merge window)
with just the patches for this tool. This topic branch can then be merged
into kvm/next and s390/features.
b: split out the kvm defines into arch/s390/tools/kvm_facilities.h


b would like something like this (cut/paste so whitespace damaged)


From: Christian Borntraeger <borntraeger@de.ibm.com>
Date: Wed, 23 Nov 2016 09:18:42 +0100
Subject: [PATCH 1/1] s390:gen_facilites: Move kvm facilities into a separate
 file

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 MAINTAINERS                      |  1 +
 arch/s390/tools/gen_facilities.c | 25 +------------------------
 arch/s390/tools/kvm_facilities.c | 26 ++++++++++++++++++++++++++
 3 files changed, 28 insertions(+), 24 deletions(-)
 create mode 100644 arch/s390/tools/kvm_facilities.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ad9b965..941d555 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6928,6 +6928,7 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git
 S:	Supported
 F:	Documentation/s390/kvm.txt
 F:	arch/s390/include/asm/kvm*
+F:	arch/s390/tools/kvm_facilities.c
 F:	arch/s390/kvm/
 
 KERNEL VIRTUAL MACHINE (KVM) FOR ARM
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 8cc53b1..af91c69 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -59,30 +59,7 @@ static struct facility_def facility_defs[] = {
 			-1 /* END */
 		}
 	},
-	{
-		.name = "FACILITIES_KVM",
-		.bits = (int[]){
-			0,  /* N3 instructions */
-			1,  /* z/Arch mode installed */
-			2,  /* z/Arch mode active */
-			3,  /* DAT-enhancement */
-			4,  /* idte segment table */
-			5,  /* idte region table */
-			6,  /* ASN-and-LX reuse */
-			7,  /* stfle */
-			8,  /* enhanced-DAT 1 */
-			9,  /* sense-running-status */
-			10, /* conditional sske */
-			13, /* ipte-range */
-			14, /* nonquiescing key-setting */
-			73, /* transactional execution */
-			75, /* access-exception-fetch/store indication */
-			76, /* msa extension 3 */
-			77, /* msa extension 4 */
-			78, /* enhanced-DAT 2 */
-			-1  /* END */
-		}
-	},
+	#include "kvm_facilities.c"
 };
 
 static void print_facility_list(struct facility_def *def)
diff --git a/arch/s390/tools/kvm_facilities.c b/arch/s390/tools/kvm_facilities.c
new file mode 100644
index 0000000..f6bb1ae
--- /dev/null
+++ b/arch/s390/tools/kvm_facilities.c
@@ -0,0 +1,26 @@
+/* To be included by arch/s390/tools/gen_facilities.c */
+	{
+		.name = "FACILITIES_KVM",
+		.bits = (int[]){
+			0,  /* N3 instructions */
+			1,  /* z/Arch mode installed */
+			2,  /* z/Arch mode active */
+			3,  /* DAT-enhancement */
+			4,  /* idte segment table */
+			5,  /* idte region table */
+			6,  /* ASN-and-LX reuse */
+			7,  /* stfle */
+			8,  /* enhanced-DAT 1 */
+			9,  /* sense-running-status */
+			10, /* conditional sske */
+			13, /* ipte-range */
+			14, /* nonquiescing key-setting */
+			73, /* transactional execution */
+			75, /* access-exception-fetch/store indication */
+			76, /* msa extension 3 */
+			77, /* msa extension 4 */
+			78, /* enhanced-DAT 2 */
+			-1  /* END */
+		}
+	},
+
-- 
2.5.5

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Heiko Carstens]

On Wed, Nov 23, 2016 at 09:24:17AM +0100, Christian Borntraeger wrote:
> On 11/23/2016 04:45 AM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the kvms390 tree got a conflict in:
> > 
> >   arch/s390/include/asm/facilities_src.h
> > 
> > between commit:
> > 
> >   d1f7e8f85b51 ("s390: squash facilities_src.h into gen_facilities.c")
> > 
> > from the s390 tree and commits:
> > 
> >   09ff894457e9 ("KVM: s390: gaccess: add ESOP2 handling")
> >   88abf0b54f51 ("KVM: s390: instruction-execution-protection support")
> > 
> > from the kvms390 tree.
> > 
> > I fixed it up (I deleted the file and then added 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.
> 
> Thanks, looks fine.
> 
> Hmmm, Martin, Heiko, KVM is going to touch that file from time to time.
> Can we either have 
> a: a topic branch for this tool (like I did for the 4.9 merge window)
> with just the patches for this tool. This topic branch can then be merged
> into kvm/next and s390/features.

That's up to Martin.

> b: split out the kvm defines into arch/s390/tools/kvm_facilities.h
> b would like something like this (cut/paste so whitespace damaged)
> 
> From: Christian Borntraeger <borntraeger@de.ibm.com>
> Date: Wed, 23 Nov 2016 09:18:42 +0100
> Subject: [PATCH 1/1] s390:gen_facilites: Move kvm facilities into a separate
>  file
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  MAINTAINERS                      |  1 +
>  arch/s390/tools/gen_facilities.c | 25 +------------------------
>  arch/s390/tools/kvm_facilities.c | 26 ++++++++++++++++++++++++++
>  3 files changed, 28 insertions(+), 24 deletions(-)
>  create mode 100644 arch/s390/tools/kvm_facilities.c

No, please don't split this file again. Only kvm will ever touch the kvm
facilities, so we won't any conflicts here.
This time it's only because the file moved, otherwise there wouldn't be any
problem at all.

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

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

Hi all,

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

  drivers/s390/crypto/vfio_ap_ops.c

between commit:

  0daf9878a799 ("s390/vfio_ap: check TAPQ response code when waiting for queue reset")

from the s390 tree and commit:

  bedac519eefa ("s390/vfio-ap: check TAPQ response code when waiting for queue reset")

from the kvms390 tree.

They seem to do the same thing, so I used the version of this file from
the s390 tree as it's commit is much newer and has other changes to this
file i.e. I effectively dropped the kvms390 tree commit.

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

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

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Christian Borntraeger]

Am 23.01.23 um 02:12 schrieb Stephen Rothwell:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>    drivers/s390/crypto/vfio_ap_ops.c
> 
> between commit:
> 
>    0daf9878a799 ("s390/vfio_ap: check TAPQ response code when waiting for queue reset")
> 
> from the s390 tree and commit:
> 
>    bedac519eefa ("s390/vfio-ap: check TAPQ response code when waiting for queue reset")
> 
> from the kvms390 tree.
> 
> They seem to do the same thing, so I used the version of this file from
> the s390 tree as it's commit is much newer and has other changes to this
> file i.e. I effectively dropped the kvms390 tree commit.
> 
> I fixed it up (see above) 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.

Yes thanks, will drop from the kvms390 tree.

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Anthony Krowiak]

On 1/22/23 8:12 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvms390 tree got a conflict in:
>
>    drivers/s390/crypto/vfio_ap_ops.c
>
> between commit:
>
>    0daf9878a799 ("s390/vfio_ap: check TAPQ response code when waiting for queue reset")
>
> from the s390 tree and commit:
>
>    bedac519eefa ("s390/vfio-ap: check TAPQ response code when waiting for queue reset")
>
> from the kvms390 tree.
>
> They seem to do the same thing, so I used the version of this file from
> the s390 tree as it's commit is much newer and has other changes to this
> file i.e. I effectively dropped the kvms390 tree commit.


That's odd, the patch series posted to the kernel mailing lists did not 
have both of those patches. I think the problem may have occurred 
because there was an earlier version of the patch in question that was 
used to debug a problem in our CI. That patch should have been reverted 
prior to installing the latest version.


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

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Christian Borntraeger]

hAm 23.01.23 um 20:02 schrieb Anthony Krowiak:
> 
> On 1/22/23 8:12 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>
>>    drivers/s390/crypto/vfio_ap_ops.c
>>
>> between commit:
>>
>>    0daf9878a799 ("s390/vfio_ap: check TAPQ response code when waiting for queue reset")
>>
>> from the s390 tree and commit:
>>
>>    bedac519eefa ("s390/vfio-ap: check TAPQ response code when waiting for queue reset")
>>
>> from the kvms390 tree.
>>
>> They seem to do the same thing, so I used the version of this file from
>> the s390 tree as it's commit is much newer and has other changes to this
>> file i.e. I effectively dropped the kvms390 tree commit.
> 
> 
> That's odd, the patch series posted to the kernel mailing lists did not have both of those patches. I think the problem may have occurred because there was an earlier version of the patch in question that was used to debug a problem in our CI. That patch should have been reverted prior to installing the latest version.


Yes, that patch was part of the kvms390 tree and it was old. I removed it. Sorry for the left-over
The one in the s390 tree is the correct one:

https://lore.kernel.org/all/20230118203111.529766-3-akrowiak@linux.ibm.com/
is now
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=for-next&id=0daf9878a7990058e74025493820bce0f67654c4

this should be ok now?

Christian

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Anthony Krowiak]

On 1/24/23 6:19 AM, Christian Borntraeger wrote:
> hAm 23.01.23 um 20:02 schrieb Anthony Krowiak:
>>
>> On 1/22/23 8:12 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>>
>>>    drivers/s390/crypto/vfio_ap_ops.c
>>>
>>> between commit:
>>>
>>>    0daf9878a799 ("s390/vfio_ap: check TAPQ response code when 
>>> waiting for queue reset")
>>>
>>> from the s390 tree and commit:
>>>
>>>    bedac519eefa ("s390/vfio-ap: check TAPQ response code when 
>>> waiting for queue reset")
>>>
>>> from the kvms390 tree.
>>>
>>> They seem to do the same thing, so I used the version of this file from
>>> the s390 tree as it's commit is much newer and has other changes to 
>>> this
>>> file i.e. I effectively dropped the kvms390 tree commit.
>>
>>
>> That's odd, the patch series posted to the kernel mailing lists did 
>> not have both of those patches. I think the problem may have occurred 
>> because there was an earlier version of the patch in question that 
>> was used to debug a problem in our CI. That patch should have been 
>> reverted prior to installing the latest version.
>
>
> Yes, that patch was part of the kvms390 tree and it was old. I removed 
> it. Sorry for the left-over
> The one in the s390 tree is the correct one:
>
> https://lore.kernel.org/all/20230118203111.529766-3-akrowiak@linux.ibm.com/ 
>
> is now
> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=for-next&id=0daf9878a7990058e74025493820bce0f67654c4 
>
>
> this should be ok now?


Yes, that is the correct one.


>
> Christian

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

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

Hi all,

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

  arch/s390/mm/init.c

between commit:

  2ce7a18211b0 ("s390/mm: fix virtual-physical address confusion for swiotlb")

from the s390 tree and commit:

  58635d6615f1 ("s390/mm: fix virtual-physical address confusion for swiotlb")

from the kvms390 tree.

I fixed it up (I just used the latter version) 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

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

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

Hi all,

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

  arch/s390/kvm/gaccess.c

between commit:

  a75259825401 ("s390: rename struct psw_bits members")

from the s390 tree and commit:

  8993df124642 ("KVM: s390: implement instruction execution protection for emulated")

from the kvms390 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/s390/kvm/gaccess.c
index e0f7d5fc7efd,6fda095f1a99..000000000000
--- a/arch/s390/kvm/gaccess.c
+++ b/arch/s390/kvm/gaccess.c
@@@ -790,8 -808,8 +808,8 @@@ static int guest_page_range(struct kvm_
  			return trans_exc(vcpu, PGM_PROTECTION, ga, ar, mode,
  					 PROT_TYPE_LA);
  		ga &= PAGE_MASK;
 -		if (psw_bits(*psw).t) {
 +		if (psw_bits(*psw).dat) {
- 			rc = guest_translate(vcpu, ga, pages, asce, mode);
+ 			rc = guest_translate(vcpu, ga, pages, asce, mode, &prot);
  			if (rc < 0)
  				return rc;
  		} else {
@@@ -899,10 -918,10 +918,10 @@@ int guest_translate_address(struct kvm_
  					 mode, PROT_TYPE_LA);
  	}
  
 -	if (psw_bits(*psw).t && !asce.r) {	/* Use DAT? */
 +	if (psw_bits(*psw).dat && !asce.r) {	/* Use DAT? */
- 		rc = guest_translate(vcpu, gva, gpa, asce, mode);
+ 		rc = guest_translate(vcpu, gva, gpa, asce, mode, &prot);
  		if (rc > 0)
- 			return trans_exc(vcpu, rc, gva, 0, mode, PROT_TYPE_DAT);
+ 			return trans_exc(vcpu, rc, gva, 0, mode, prot);
  	} else {
  		*gpa = kvm_s390_real_to_abs(vcpu, gva);
  		if (kvm_is_error_gpa(vcpu->kvm, *gpa))

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

Hi all,

[cc'ing kvm tree maintainers]

Withe the merge window opening, just a reminder that this conflict
still exists.

On Thu, 22 Jun 2017 12:59:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   arch/s390/kvm/gaccess.c
> 
> between commit:
> 
>   a75259825401 ("s390: rename struct psw_bits members")
> 
> from the s390 tree and commit:
> 
>   8993df124642 ("KVM: s390: implement instruction execution protection for emulated")
> 
> from the kvms390 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/s390/kvm/gaccess.c
> index e0f7d5fc7efd,6fda095f1a99..000000000000
> --- a/arch/s390/kvm/gaccess.c
> +++ b/arch/s390/kvm/gaccess.c
> @@@ -790,8 -808,8 +808,8 @@@ static int guest_page_range(struct kvm_
>   			return trans_exc(vcpu, PGM_PROTECTION, ga, ar, mode,
>   					 PROT_TYPE_LA);
>   		ga &= PAGE_MASK;
>  -		if (psw_bits(*psw).t) {
>  +		if (psw_bits(*psw).dat) {
> - 			rc = guest_translate(vcpu, ga, pages, asce, mode);
> + 			rc = guest_translate(vcpu, ga, pages, asce, mode, &prot);
>   			if (rc < 0)
>   				return rc;
>   		} else {
> @@@ -899,10 -918,10 +918,10 @@@ int guest_translate_address(struct kvm_
>   					 mode, PROT_TYPE_LA);
>   	}
>   
>  -	if (psw_bits(*psw).t && !asce.r) {	/* Use DAT? */
>  +	if (psw_bits(*psw).dat && !asce.r) {	/* Use DAT? */
> - 		rc = guest_translate(vcpu, gva, gpa, asce, mode);
> + 		rc = guest_translate(vcpu, gva, gpa, asce, mode, &prot);
>   		if (rc > 0)
> - 			return trans_exc(vcpu, rc, gva, 0, mode, PROT_TYPE_DAT);
> + 			return trans_exc(vcpu, rc, gva, 0, mode, prot);
>   	} else {
>   		*gpa = kvm_s390_real_to_abs(vcpu, gva);
>   		if (kvm_is_error_gpa(vcpu->kvm, *gpa))

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

Hi all,

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

  arch/s390/include/asm/cpacf.h

between commit:

  985a9d20daa6 ("s390/crypto: Renaming PPNO to PRNO.")

from the s390 tree and commit:

  152c1c8d60eb ("s390/cpacf: Introduce kma instruction")

from the kvms390 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/s390/include/asm/cpacf.h
index 7707a35176c4,31cac7d17b48..000000000000
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@@ -25,7 -25,8 +25,8 @@@
  #define CPACF_KMO		0xb92b		/* MSA4 */
  #define CPACF_PCC		0xb92c		/* MSA4 */
  #define CPACF_KMCTR		0xb92d		/* MSA4 */
 -#define CPACF_PPNO		0xb93c		/* MSA5 */
 +#define CPACF_PRNO		0xb93c		/* MSA5 */
+ #define CPACF_KMA		0xb929		/* MSA8 */
  
  /*
   * En/decryption modifier bits

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Christian Borntraeger]

On 04/27/2017 05:29 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   arch/s390/include/asm/cpacf.h
> 
> between commit:
> 
>   985a9d20daa6 ("s390/crypto: Renaming PPNO to PRNO.")
> 
> from the s390 tree and commit:
> 
>   152c1c8d60eb ("s390/cpacf: Introduce kma instruction")
> 
> from the kvms390 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.
> 

Correct fix, thanks. It should be ok again tomorrow as Martin has merged
my topic branch.

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

Hi all,

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

  arch/s390/hypfs/hypfs_diag.c

between commit:

  6c22c9863760 ("s390: avoid extable collisions")

from the s390 tree and commit:

  e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")

from the kvms390 tree.

I fixed it up (using the kvms390 version and then adding 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: Tue, 14 Jun 2016 14:47:33 +1000
Subject: [PATCH] s390: merge fix up for __diag204 move

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

diff --git a/arch/s390/kernel/diag.c b/arch/s390/kernel/diag.c
index a44faf4a0454..2289d6f8bec0 100644
--- a/arch/s390/kernel/diag.c
+++ b/arch/s390/kernel/diag.c
@@ -169,7 +169,7 @@ static inline int __diag204(unsigned long subcode, unsigned long size, void *add
 
 	asm volatile(
 		"	diag	%2,%0,0x204\n"
-		"0:\n"
+		"0:	nopr	%%r7\n"
 		EX_TABLE(0b,0b)
 		: "+d" (_subcode), "+d" (_size) : "d" (addr) : "memory");
 	if (_subcode)
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Heiko Carstens]

On Tue, Jun 14, 2016 at 02:51:17PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   arch/s390/hypfs/hypfs_diag.c
> 
> between commit:
> 
>   6c22c9863760 ("s390: avoid extable collisions")
> 
> from the s390 tree and commit:
> 
>   e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")
> 
> from the kvms390 tree.
> 
> I fixed it up (using the kvms390 version and then adding 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: Tue, 14 Jun 2016 14:47:33 +1000
> Subject: [PATCH] s390: merge fix up for __diag204 move
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/s390/kernel/diag.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kernel/diag.c b/arch/s390/kernel/diag.c
> index a44faf4a0454..2289d6f8bec0 100644
> --- a/arch/s390/kernel/diag.c
> +++ b/arch/s390/kernel/diag.c
> @@ -169,7 +169,7 @@ static inline int __diag204(unsigned long subcode, unsigned long size, void *add
> 
>  	asm volatile(
>  		"	diag	%2,%0,0x204\n"
> -		"0:\n"
> +		"0:	nopr	%%r7\n"
>  		EX_TABLE(0b,0b)
>  		: "+d" (_subcode), "+d" (_size) : "d" (addr) : "memory");
>  	if (_subcode)

The patch looks good. Thank you!

Re: linux-next: manual merge of the kvms390 tree with the s390 tree

[Christian Borntraeger]

On 06/14/2016 06:51 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   arch/s390/hypfs/hypfs_diag.c
> 
> between commit:
> 
>   6c22c9863760 ("s390: avoid extable collisions")
> 
> from the s390 tree and commit:
> 
>   e65f30e0cb29 ("s390: hypfs: Move diag implementation and data definitions")
> 
> from the kvms390 tree.
> 
> I fixed it up (using the kvms390 version and then adding 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: Tue, 14 Jun 2016 14:47:33 +1000
> Subject: [PATCH] s390: merge fix up for __diag204 move
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/s390/kernel/diag.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kernel/diag.c b/arch/s390/kernel/diag.c
> index a44faf4a0454..2289d6f8bec0 100644
> --- a/arch/s390/kernel/diag.c
> +++ b/arch/s390/kernel/diag.c
> @@ -169,7 +169,7 @@ static inline int __diag204(unsigned long subcode, unsigned long size, void *add
> 
>  	asm volatile(
>  		"	diag	%2,%0,0x204\n"
> -		"0:\n"
> +		"0:	nopr	%%r7\n"
>  		EX_TABLE(0b,0b)
>  		: "+d" (_subcode), "+d" (_size) : "d" (addr) : "memory");
>  	if (_subcode)
> 


Yes, thanks. This conflict (and the other preexisting one) will move soon to Paolos KVM tree
as I plan to submit my first pull request soon.

Christian 

linux-next: manual merge of the kvms390 tree with the s390 tree

[Stephen Rothwell]

Hi all,

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

  arch/s390/kernel/entry.S

between commit:

  2a1a14484b97 ("s390/kernel: lazy restore fpu registers")
  3af40983a937 ("s390/kvm: fix interrupt race with HANDLE_SIE_INTERCEPT")
  0be8cda612d8 ("s390/kvm: integrate HANDLE_SIE_INTERCEPT into cleanup_critical")

from the s390 tree and commit:

  e983d24d6117 ("KVM: s390: use pid of cpu thread for sampling tagging")

from the kvms390 tree.

I fixed it up (maybe? see below) and can carry the fix as necessary
(no action is required - unless this fix is just wrong).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/s390/kernel/entry.S
index bde6275dd813,0dfa5f4ce755..000000000000
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@@ -169,70 -193,6 +169,70 @@@ ENTRY(__switch_to
  	br	%r14
  
  .L__critical_start:
 +
 +#if IS_ENABLED(CONFIG_KVM)
 +/*
 + * sie64a calling convention:
 + * %r2 pointer to sie control block
 + * %r3 guest register save area
 + */
 +ENTRY(sie64a)
 +	stmg	%r6,%r14,__SF_GPRS(%r15)	# save kernel registers
 +	stg	%r2,__SF_EMPTY(%r15)		# save control block pointer
 +	stg	%r3,__SF_EMPTY+8(%r15)		# save guest register save area
 +	xc	__SF_EMPTY+16(16,%r15),__SF_EMPTY+16(%r15) # host id & reason
 +	tm	__LC_CPU_FLAGS+7,_CIF_FPU	# load guest fp/vx registers ?
 +	jno	.Lsie_load_guest_gprs
 +	lg	%r12,__LC_THREAD_INFO		# load fp/vx regs save area
 +	brasl	%r14,load_fpu_regs		# load guest fp/vx regs
 +.Lsie_load_guest_gprs:
 +	lmg	%r0,%r13,0(%r3)			# load guest gprs 0-13
 +	lg	%r14,__LC_GMAP			# get gmap pointer
 +	ltgr	%r14,%r14
 +	jz	.Lsie_gmap
 +	lctlg	%c1,%c1,__GMAP_ASCE(%r14)	# load primary asce
 +.Lsie_gmap:
 +	lg	%r14,__SF_EMPTY(%r15)		# get control block pointer
 +	oi	__SIE_PROG0C+3(%r14),1		# we are going into SIE now
 +	tm	__SIE_PROG20+3(%r14),3		# last exit...
 +	jnz	.Lsie_skip
 +	tm	__LC_CPU_FLAGS+7,_CIF_FPU
 +	jo	.Lsie_skip			# exit if fp/vx regs changed
 +	tm	__LC_MACHINE_FLAGS+6,0x20	# MACHINE_FLAG_LPP
 +	jz	.Lsie_enter
- 	.insn	s,0xb2800000,__SF_EMPTY(%r15)	# set guest id
++	.insn	s,0xb2800000,__LC_CURRENT_PID	# use cpu thread pid
 +.Lsie_enter:
 +	sie	0(%r14)
 +	tm	__LC_MACHINE_FLAGS+6,0x20	# MACHINE_FLAG_LPP
 +	jz	.Lsie_skip
 +	.insn	s,0xb2800000,__SF_EMPTY+16(%r15)# set host id
 +.Lsie_skip:
 +	ni	__SIE_PROG0C+3(%r14),0xfe	# no longer in SIE
 +	lctlg	%c1,%c1,__LC_USER_ASCE		# load primary asce
 +.Lsie_done:
 +# some program checks are suppressing. C code (e.g. do_protection_exception)
 +# will rewind the PSW by the ILC, which is 4 bytes in case of SIE. Other
 +# instructions between sie64a and .Lsie_done should not cause program
 +# interrupts. So lets use a nop (47 00 00 00) as a landing pad.
 +# See also .Lcleanup_sie
 +.Lrewind_pad:
 +	nop	0
 +	.globl sie_exit
 +sie_exit:
 +	lg	%r14,__SF_EMPTY+8(%r15)		# load guest register save area
 +	stmg	%r0,%r13,0(%r14)		# save guest gprs 0-13
 +	lmg	%r6,%r14,__SF_GPRS(%r15)	# restore kernel registers
 +	lg	%r2,__SF_EMPTY+24(%r15)		# return exit reason code
 +	br	%r14
 +.Lsie_fault:
 +	lghi	%r14,-EFAULT
 +	stg	%r14,__SF_EMPTY+24(%r15)	# set exit reason code
 +	j	sie_exit
 +
 +	EX_TABLE(.Lrewind_pad,.Lsie_fault)
 +	EX_TABLE(sie_exit,.Lsie_fault)
 +#endif
 +
  /*
   * SVC interrupt handler routine. System calls are synchronous events and
   * are executed with interrupts enabled.