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, 18 Mar 2015 11:59:27 +0100 Message-ID: <55095A8F.6070809@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> <54F6EB0D.1030106@suse.com> <1425469278.25940.144.camel@citrix.com> <5507C09B.6070001@suse.com> <1426672789.18247.295.camel@citrix.com> 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 1YYBhE-0004Bd-5K for xen-devel@lists.xenproject.org; Wed, 18 Mar 2015 10:59:32 +0000 In-Reply-To: <1426672789.18247.295.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: keir@xen.org, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, Tim Deegan , david.vrabel@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 03/18/2015 10:59 AM, Ian Campbell wrote: > On Tue, 2015-03-17 at 06:50 +0100, Juergen Gross wrote: >> On 03/04/2015 12:41 PM, Ian Campbell wrote: >>> On Wed, 2015-03-04 at 12:22 +0100, Juergen Gross wrote: >>>> It would either be used like intended, >>> >>> Which is how? That is what is really missing here. >>> >>> So far this appears to be a bit which enables some as yet unspecified[0] >>> behaviour in one particular OS kernel with some as yet undiscussed >>> potential future impact on toolstack functionality. >> >> Sorry for the late answer, but I managed to move this mail to my archive >> before reacting on it. :-( > > No problem. > > The description looks like the sort of thing which ought to go into the > commit log. Okay, I can change it. > Is there not an ABI change somewhere else relating to the exposure of > the cr3+vaddr+size? If so why is it not in this patch? Commit 50bd1f0825339dfacde471df7664729216fc46e3 > Ideally whichever file which needs to change in xen/include/public to > expose that change should also come along with documentation for this > new ABI. Included in above commit in form of comments in the modified file. > If that change has been deferred for some reason then I think it (and > why) should be mentioned in the commit message, you'll also want to > explain why adding the bit now but the ABI change later is safe, i.e. > what the transition plan is. > > AIUI this change has broken memory hotplug and has also made it > difficult from an ABI PoV to reinstate that support. I think that needs > to be addressed (i.e. at the ABI design level, not necessary > implemented) before we add a bit exposing this feature. The interface change didn't brake anything. It was the implementation in the Linux kernel. >> Guests implementing this new interface need to know, of course, whether >> the Xen tools are capable to use the new interface instead of the old >> p2m tree interface. Otherwise a guest using only the new interface with >> the virtual mapped linear p2m list on a machine with old Xen tools not >> supporting this interface could not be restored or migrated. > > What is the mechanism for the converse, i.e. for the tools to detect if > a given guest is making use of this functionality? See above commit. It's all in the comments. > Are tools going to be able to tell at migration time, or is it something > which needs to be detectable at domain build time (and therefore exposed > in the kernel ELF notes)? Migration time is fine. Juergen