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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
