* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2016-06-14 4:51 Stephen Rothwell
2016-06-14 4:52 ` Heiko Carstens
2016-06-14 8:45 ` Christian Borntraeger
0 siblings, 2 replies; 17+ messages in thread
From: Stephen Rothwell @ 2016-06-14 4:51 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: linux-next, linux-kernel, Janosch Frank
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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2016-06-14 4:51 linux-next: manual merge of the kvms390 tree with the s390 tree Stephen Rothwell
@ 2016-06-14 4:52 ` Heiko Carstens
2016-06-14 8:45 ` Christian Borntraeger
1 sibling, 0 replies; 17+ messages in thread
From: Heiko Carstens @ 2016-06-14 4:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky,
linux-next, linux-kernel, Janosch Frank
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!
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2016-06-14 4:51 linux-next: manual merge of the kvms390 tree with the s390 tree Stephen Rothwell
2016-06-14 4:52 ` Heiko Carstens
@ 2016-06-14 8:45 ` Christian Borntraeger
1 sibling, 0 replies; 17+ messages in thread
From: Christian Borntraeger @ 2016-06-14 8:45 UTC (permalink / raw)
To: Stephen Rothwell, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: linux-next, linux-kernel, Janosch Frank, Paolo Bonzini
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2023-01-24 11:19 ` Christian Borntraeger
@ 2023-01-24 14:43 ` Anthony Krowiak
0 siblings, 0 replies; 17+ messages in thread
From: Anthony Krowiak @ 2023-01-24 14:43 UTC (permalink / raw)
To: Christian Borntraeger, Stephen Rothwell, Janosch Frank,
Heiko Carstens, Vasily Gorbik
Cc: Linux Kernel Mailing List, Linux Next Mailing List
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2023-01-23 19:02 ` Anthony Krowiak
@ 2023-01-24 11:19 ` Christian Borntraeger
2023-01-24 14:43 ` Anthony Krowiak
0 siblings, 1 reply; 17+ messages in thread
From: Christian Borntraeger @ 2023-01-24 11:19 UTC (permalink / raw)
To: Anthony Krowiak, Stephen Rothwell, Janosch Frank, Heiko Carstens,
Vasily Gorbik
Cc: Christian Borntraeger, Linux Kernel Mailing List,
Linux Next Mailing List
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2023-01-23 1:12 Stephen Rothwell
2023-01-23 7:07 ` Christian Borntraeger
@ 2023-01-23 19:02 ` Anthony Krowiak
2023-01-24 11:19 ` Christian Borntraeger
1 sibling, 1 reply; 17+ messages in thread
From: Anthony Krowiak @ 2023-01-23 19:02 UTC (permalink / raw)
To: Stephen Rothwell, Christian Borntraeger, Janosch Frank,
Heiko Carstens, Vasily Gorbik
Cc: Christian Borntraeger, Linux Kernel Mailing List,
Linux Next Mailing List
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.
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2023-01-23 1:12 Stephen Rothwell
@ 2023-01-23 7:07 ` Christian Borntraeger
2023-01-23 19:02 ` Anthony Krowiak
1 sibling, 0 replies; 17+ messages in thread
From: Christian Borntraeger @ 2023-01-23 7:07 UTC (permalink / raw)
To: Stephen Rothwell, Janosch Frank, Heiko Carstens, Vasily Gorbik
Cc: Christian Borntraeger, Linux Kernel Mailing List,
Linux Next Mailing List, Tony Krowiak
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2023-01-23 1:12 Stephen Rothwell
2023-01-23 7:07 ` Christian Borntraeger
2023-01-23 19:02 ` Anthony Krowiak
0 siblings, 2 replies; 17+ messages in thread
From: Stephen Rothwell @ 2023-01-23 1:12 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank, Heiko Carstens, Vasily Gorbik
Cc: Christian Borntraeger, Linux Kernel Mailing List,
Linux Next Mailing List, Tony Krowiak
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2022-11-08 2:41 Stephen Rothwell
0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2022-11-08 2:41 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank, Heiko Carstens, Vasily Gorbik
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Nico Boehr
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2017-06-22 2:59 Stephen Rothwell
@ 2017-07-03 1:55 ` Stephen Rothwell
0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2017-07-03 1:55 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Marcelo Tosatti, Gleb Natapov, KVM
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2017-06-22 2:59 Stephen Rothwell
2017-07-03 1:55 ` Stephen Rothwell
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2017-06-22 2:59 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
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))
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2017-04-27 3:29 Stephen Rothwell
@ 2017-04-27 6:47 ` Christian Borntraeger
0 siblings, 0 replies; 17+ messages in thread
From: Christian Borntraeger @ 2017-04-27 6:47 UTC (permalink / raw)
To: Stephen Rothwell, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Harald Freudenberger, Jason J. Herne
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2017-04-27 3:29 Stephen Rothwell
2017-04-27 6:47 ` Christian Borntraeger
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2017-04-27 3:29 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Harald Freudenberger, Jason J. Herne
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2016-11-23 8:24 ` Christian Borntraeger
@ 2016-11-23 9:17 ` Heiko Carstens
0 siblings, 0 replies; 17+ messages in thread
From: Heiko Carstens @ 2016-11-23 9:17 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Stephen Rothwell, Cornelia Huck, Martin Schwidefsky, linux-next,
linux-kernel, Masahiro Yamada, Janosch Frank
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: manual merge of the kvms390 tree with the s390 tree
2016-11-23 3:45 Stephen Rothwell
@ 2016-11-23 8:24 ` Christian Borntraeger
2016-11-23 9:17 ` Heiko Carstens
0 siblings, 1 reply; 17+ messages in thread
From: Christian Borntraeger @ 2016-11-23 8:24 UTC (permalink / raw)
To: Stephen Rothwell, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: linux-next, linux-kernel, Masahiro Yamada, Janosch Frank
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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2016-11-23 3:45 Stephen Rothwell
2016-11-23 8:24 ` Christian Borntraeger
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2016-11-23 3:45 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: linux-next, linux-kernel, Masahiro Yamada, Janosch Frank
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
^ permalink raw reply related [flat|nested] 17+ messages in thread
* linux-next: manual merge of the kvms390 tree with the s390 tree
@ 2015-07-22 2:31 Stephen Rothwell
0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2015-07-22 2:31 UTC (permalink / raw)
To: Christian Borntraeger, Cornelia Huck, Martin Schwidefsky, Heiko Carstens
Cc: linux-next, linux-kernel, Hendrik Brueckner
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2023-01-24 14:43 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-14 4:51 linux-next: manual merge of the kvms390 tree with the s390 tree Stephen Rothwell
2016-06-14 4:52 ` Heiko Carstens
2016-06-14 8:45 ` Christian Borntraeger
-- strict thread matches above, loose matches on Subject: below --
2023-01-23 1:12 Stephen Rothwell
2023-01-23 7:07 ` Christian Borntraeger
2023-01-23 19:02 ` Anthony Krowiak
2023-01-24 11:19 ` Christian Borntraeger
2023-01-24 14:43 ` Anthony Krowiak
2022-11-08 2:41 Stephen Rothwell
2017-06-22 2:59 Stephen Rothwell
2017-07-03 1:55 ` Stephen Rothwell
2017-04-27 3:29 Stephen Rothwell
2017-04-27 6:47 ` Christian Borntraeger
2016-11-23 3:45 Stephen Rothwell
2016-11-23 8:24 ` Christian Borntraeger
2016-11-23 9:17 ` Heiko Carstens
2015-07-22 2:31 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).