linux-next: manual merge of the kvms390 tree with the kvm-mips tree

linux-next: manual merge of the kvms390 tree with the kvm-mips tree

[Stephen Rothwell]

Hi all,

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

  include/uapi/linux/kvm.h

between commits:

  a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
  578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")

from the kvm-mips tree and commit:

  4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")

from the kvms390 tree.

It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...

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 include/uapi/linux/kvm.h
index 1e1a6c728a18,c9d522765f8f..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_PPC_MMU_RADIX 134
  #define KVM_CAP_PPC_MMU_HASH_V3 135
  #define KVM_CAP_IMMEDIATE_EXIT 136
 -#define KVM_CAP_S390_GS 137
 +#define KVM_CAP_MIPS_VZ 137
 +#define KVM_CAP_MIPS_TE 138
 +#define KVM_CAP_MIPS_64BIT 139
++#define KVM_CAP_S390_GS 140
  
  #ifdef KVM_CAP_IRQ_ROUTING
  

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

[James Hogan]

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

On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvms390 tree got a conflict in:
> 
>   include/uapi/linux/kvm.h
> 
> between commits:
> 
>   a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
>   578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
> 
> from the kvm-mips tree and commit:
> 
>   4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
> 
> from the kvms390 tree.
> 
> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
> 
> 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 include/uapi/linux/kvm.h
> index 1e1a6c728a18,c9d522765f8f..000000000000
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
>   #define KVM_CAP_PPC_MMU_RADIX 134
>   #define KVM_CAP_PPC_MMU_HASH_V3 135
>   #define KVM_CAP_IMMEDIATE_EXIT 136
>  -#define KVM_CAP_S390_GS 137
>  +#define KVM_CAP_MIPS_VZ 137
>  +#define KVM_CAP_MIPS_TE 138
>  +#define KVM_CAP_MIPS_64BIT 139
> ++#define KVM_CAP_S390_GS 140
>   
>   #ifdef KVM_CAP_IRQ_ROUTING

Thanks Stephen,

Cc'ing Paulo and Radim.

This does seem a bit of a conflict magnet, and they're part of the user
ABI so when the values change upon merge, the intermediate versions
before and after require different userland builds.

Should the numbering be decided in advance somehow (i.e. in response to
conflicts in linux-next)? I don't particularly want to change the
numbering again as others would need rebuilds again, but I only just
pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
can we expect other branches to continue at 141 so I don't need to
change them again?

Alternatively does it make sense to have different ranges reserved for
different architectures (like the get one reg numbers)?

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Christian Borntraeger]

On 03/29/2017 11:21 AM, James Hogan wrote:
> On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvms390 tree got a conflict in:
>>
>>   include/uapi/linux/kvm.h
>>
>> between commits:
>>
>>   a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
>>   578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
>>
>> from the kvm-mips tree and commit:
>>
>>   4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
>>
>> from the kvms390 tree.
>>
>> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
>>
>> 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 include/uapi/linux/kvm.h
>> index 1e1a6c728a18,c9d522765f8f..000000000000
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
>>   #define KVM_CAP_PPC_MMU_RADIX 134
>>   #define KVM_CAP_PPC_MMU_HASH_V3 135
>>   #define KVM_CAP_IMMEDIATE_EXIT 136
>>  -#define KVM_CAP_S390_GS 137
>>  +#define KVM_CAP_MIPS_VZ 137
>>  +#define KVM_CAP_MIPS_TE 138
>>  +#define KVM_CAP_MIPS_64BIT 139
>> ++#define KVM_CAP_S390_GS 140
>>   
>>   #ifdef KVM_CAP_IRQ_ROUTING
> 
> Thanks Stephen,
> 
> Cc'ing Paulo and Radim.
> 
> This does seem a bit of a conflict magnet, and they're part of the user
> ABI so when the values change upon merge, the intermediate versions
> before and after require different userland builds.
> 
> Should the numbering be decided in advance somehow (i.e. in response to
> conflicts in linux-next)? I don't particularly want to change the
> numbering again as others would need rebuilds again, but I only just
> pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
> can we expect other branches to continue at 141 so I don't need to
> change them again?
> 
> Alternatively does it make sense to have different ranges reserved for
> different architectures (like the get one reg numbers)?

I can live with a changing GS capability number, so keep your number.
In the end I think Radim/Paolo will do the assigment when merging.
And no userspace should rely on this before this is at least in kvm/next
Yes, this will be a bit of pain for internal QA, but this worked ok
for the last 3 or 4 years on our side

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

[Paolo Bonzini]

On 29/03/2017 11:29, Christian Borntraeger wrote:
>>>  -#define KVM_CAP_S390_GS 137
>>>  +#define KVM_CAP_MIPS_VZ 137
>>>  +#define KVM_CAP_MIPS_TE 138
>>>  +#define KVM_CAP_MIPS_64BIT 139
>>> ++#define KVM_CAP_S390_GS 140
>>>   
>>>   #ifdef KVM_CAP_IRQ_ROUTING
>> Thanks Stephen,
>>
>> Cc'ing Paulo and Radim.
>>
>> This does seem a bit of a conflict magnet, and they're part of the user
>> ABI so when the values change upon merge, the intermediate versions
>> before and after require different userland builds.
>>
>> Should the numbering be decided in advance somehow (i.e. in response to
>> conflicts in linux-next)? I don't particularly want to change the
>> numbering again as others would need rebuilds again, but I only just
>> pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
>> can we expect other branches to continue at 141 so I don't need to
>> change them again?

Yes, that can be expected.  If you don't do it, I'll bump the capability
number as soon as I get the conflict.

If it's an issue, the solution is topic branches: as soon as you need a
capability, fire a pull request so that it gets in kvm/next.  But it
doesn't happen too often, the last times were in 4.1, 4.6 and 4.8 (three
times in 2 years).

>> Alternatively does it make sense to have different ranges reserved for
>> different architectures (like the get one reg numbers)?
> 
> I can live with a changing GS capability number, so keep your number.
> In the end I think Radim/Paolo will do the assigment when merging.

Yes---and in that case it's first come first served.

Same for ioctls, though those change even more rarely.

Paolo

> And no userspace should rely on this before this is at least in kvm/next
> Yes, this will be a bit of pain for internal QA, but this worked ok
> for the last 3 or 4 years on our side

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

[James Hogan]

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

On Wed, Mar 29, 2017 at 11:29:00AM +0200, Christian Borntraeger wrote:
> On 03/29/2017 11:21 AM, James Hogan wrote:
> > On Wed, Mar 29, 2017 at 02:08:32PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the kvms390 tree got a conflict in:
> >>
> >>   include/uapi/linux/kvm.h
> >>
> >> between commits:
> >>
> >>   a8a3c426772e ("KVM: MIPS: Add VZ & TE capabilities")
> >>   578fd61d2d21 ("KVM: MIPS: Add 64BIT capability")
> >>
> >> from the kvm-mips tree and commit:
> >>
> >>   4e0b1ab72b8a ("KVM: s390: gs support for kvm guests")
> >>
> >> from the kvms390 tree.
> >>
> >> It looks like someone needs to arbitrate on these KVM_CAP_ numbers ...
> >>
> >> 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 include/uapi/linux/kvm.h
> >> index 1e1a6c728a18,c9d522765f8f..000000000000
> >> --- a/include/uapi/linux/kvm.h
> >> +++ b/include/uapi/linux/kvm.h
> >> @@@ -887,9 -883,7 +887,10 @@@ struct kvm_ppc_resize_hpt 
> >>   #define KVM_CAP_PPC_MMU_RADIX 134
> >>   #define KVM_CAP_PPC_MMU_HASH_V3 135
> >>   #define KVM_CAP_IMMEDIATE_EXIT 136
> >>  -#define KVM_CAP_S390_GS 137
> >>  +#define KVM_CAP_MIPS_VZ 137
> >>  +#define KVM_CAP_MIPS_TE 138
> >>  +#define KVM_CAP_MIPS_64BIT 139
> >> ++#define KVM_CAP_S390_GS 140
> >>   
> >>   #ifdef KVM_CAP_IRQ_ROUTING
> > 
> > Thanks Stephen,
> > 
> > Cc'ing Paulo and Radim.
> > 
> > This does seem a bit of a conflict magnet, and they're part of the user
> > ABI so when the values change upon merge, the intermediate versions
> > before and after require different userland builds.
> > 
> > Should the numbering be decided in advance somehow (i.e. in response to
> > conflicts in linux-next)? I don't particularly want to change the
> > numbering again as others would need rebuilds again, but I only just
> > pushed the MIPS changes, so if I change the MIPS numbering to 138-140,
> > can we expect other branches to continue at 141 so I don't need to
> > change them again?
> > 
> > Alternatively does it make sense to have different ranges reserved for
> > different architectures (like the get one reg numbers)?
> 
> I can live with a changing GS capability number, so keep your number.

Okay, thanks

> In the end I think Radim/Paolo will do the assigment when merging.
> And no userspace should rely on this before this is at least in kvm/next
> Yes, this will be a bit of pain for internal QA, but this worked ok
> for the last 3 or 4 years on our side

Yeh, thats all it is, a bit of a pain, and probably just deserts for
having stuff out of tree for any length of time :)

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]