From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ed White <edmund.h.white@intel.com>
Subject: Re: [PATCH 00/11] Alternate p2m: support multiple
 copies of host p2m
Date: Fri, 13 Mar 2015 10:38:32 -0700
Message-ID: <55032098.2080607@intel.com>
References: <54B579CD.60804@intel.com>	<54B583FC.4060800@citrix.com>	<54B58E90.20309@intel.com>	<54B6151402000078000C580B@mail.emea.novell.com>	<CAErYnshkCQxHcdFXj-UDeDV9Z5Umwh3QYtDrFDuQU+U3WV1Ohw@mail.gmail.com>	<54B65C920200007800054BAD@mail.emea.novell.com>	<CAErYnsgCpzjZuDJT7vaZcbZjhTmEGS+E8d1_UF9Z0RcC4HPa_w@mail.gmail.com>	<54B6A8D9.904@intel.com>	<54B78555020000780005526B@mail.emea.novell.com>	<54B7F8A7.2010407@intel.com>	<20150115174517.GL57240@deinos.phlegethon.org>	<54B80A9B.7050000@intel.com>	<CAErYnsgQfdZ2OXjAFmNX3O+=arRcVK5D8SNnrCS3fSdeSg2G3g@mail.gmail.com>	<54F79816.9000504@intel.com>
	<CAErYnsgoZwmXrAMhCqFvhogLS_sGBNtMeeMwc3ReC_yQuvSwpw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAErYnsgoZwmXrAMhCqFvhogLS_sGBNtMeeMwc3ReC_yQuvSwpw@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Tamas K Lengyel <tamas.lengyel@zentific.com>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

>>
>> Is there any chance you might reconsider your decision not to help
>> with toolstack support of the patch series? I'm still trying to find
>> an internal resource to do that work, but right now it's the biggest
>> risk I see to getting the series into 4.6.
> 
> My comment regarding hesitation in committing toolstack code that is
> suboptimal still stands. Many people look at these as reference
> implementations, thus a faulty or suboptimal contribution here can
> have highly uncompetitive effects. IMHO that's not how open source
> should work. Of course if that's not the case for at least some
> usecases I would be happy to help with those.
> 

You are more familiar with the tools in question than I am, but
I wonder if anything would be suboptimal in the sense that you
mean it. You could argue that there may be closer to optimal ways
of intercepting an OS call for instance, but that depends on your
use-case, and I suspect is a higher level of abstraction than the
tools provide.

Single-stepping, OTOH, would not be suboptimal -- that was a
misunderstanding.

Ed