From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755463AbdC2Jri (ORCPT ); Wed, 29 Mar 2017 05:47:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32878 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755038AbdC2Jrf (ORCPT ); Wed, 29 Mar 2017 05:47:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9AE3341A50 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9AE3341A50 Subject: Re: linux-next: manual merge of the kvms390 tree with the kvm-mips tree To: Christian Borntraeger , James Hogan , Stephen Rothwell References: <20170329140832.5cbfb6ce@canb.auug.org.au> <20170329092112.GV31606@jhogan-linux.le.imgtec.org> <7115ff68-df06-10e0-6fff-e040a222a5e8@de.ibm.com> Cc: Cornelia Huck , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Fan Zhang , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= From: Paolo Bonzini Message-ID: Date: Wed, 29 Mar 2017 11:47:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <7115ff68-df06-10e0-6fff-e040a222a5e8@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 29 Mar 2017 09:47:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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