From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932125AbdC2Jbf (ORCPT ); Wed, 29 Mar 2017 05:31:35 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41864 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755123AbdC2J3T (ORCPT ); Wed, 29 Mar 2017 05:29:19 -0400 Subject: Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree To: James Hogan , Stephen Rothwell References: <20170329140832.5cbfb6ce@canb.auug.org.au> <20170329092112.GV31606@jhogan-linux.le.imgtec.org> Cc: Cornelia Huck , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Fan Zhang , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= From: Christian Borntraeger Date: Wed, 29 Mar 2017 11:29:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329092112.GV31606@jhogan-linux.le.imgtec.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17032909-0048-0000-0000-0000014136EF X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006870; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000206; SDB=6.00840297; UDB=6.00413538; IPR=6.00618241; BA=6.00005247; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014848; XFM=3.00000013; UTC=2017-03-29 09:29:05 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17032909-0049-0000-0000-00004010ADF3 Message-Id: <7115ff68-df06-10e0-6fff-e040a222a5e8@de.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-29_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703290079 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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