From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V2] Add flag to start info regarding virtual mapped p2m list Date: Wed, 04 Mar 2015 12:22:53 +0100 Message-ID: <54F6EB0D.1030106@suse.com> References: <1425374993-32028-1-git-send-email-jgross@suse.com> <54F59ABD02000078000658FB@suse.com> <54F58DA1.5000401@suse.com> <54F6D73802000078000660CF@mail.emea.novell.com> <1425461748.25940.88.camel@citrix.com> <54F6E19D020000780006611E@mail.emea.novell.com> <1425463572.25940.107.camel@citrix.com> <54F6DC89.8050106@suse.com> <1425466376.25940.134.camel@citrix.com> <20150304111811.GB93945@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YT7OE-00012f-BZ for xen-devel@lists.xenproject.org; Wed, 04 Mar 2015 11:22:58 +0000 In-Reply-To: <20150304111811.GB93945@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , Ian Campbell Cc: keir@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, david.vrabel@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 03/04/2015 12:18 PM, Tim Deegan wrote: > At 10:52 +0000 on 04 Mar (1425462776), Ian Campbell wrote: >> On Wed, 2015-03-04 at 11:20 +0100, Juergen Gross wrote: >>> I'd like to do an appropriate change in xl, but I've been told this >>> would make sense only for migration protocol V2. OTOH I don't want to >>> wait for an undefined amount of time until this will be posted, so I >>> sent the ABI change first. >>> >>> I could, of course, wait with the flag bit until xl is ready and post >>> another kernel patch then. Unfortunately this would delay Linux support >>> for automatically be able to run as a pv-domain >500GB further, so I >>> strongly recommend accepting the interface change now. >> >> Please at least sketch out a design/description of what this flag means >> to the guest and/or tools and what eventual tools support you expect >> will be needed, and perhaps some ideas regarding what that support might >> look like. >> >> Without this your proposed ABI change is just a random bit in a data >> structure with no context. > > If this is just an ordering constraint between kernel and tools work, > maybe we could just define the bit as reserved for now, while the dev work > finishes, and give it a proper name when the toolstack bits go in. I don't think this will be a proper solution. Using this bit in the kernel would either be okay in case the interface is added later to Xen, or it would be not okay making it impossible later to use that bit for other purposes. In both cases we could easily name the bit like I did. It would either be used like intended, or it would never be set thus doing no harm. Juergen