From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Wed, 17 Feb 2016 11:01:45 +0000 Message-ID: <56C45319.9010908@citrix.com> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <56B3373B02000078000CE86C@prv-mh.provo.novell.com> <22195.21299.624759.118961@mariner.uk.xensource.com> <56B3695E02000078000CE9D1@prv-mh.provo.novell.com> <56B38675.3050008@citrix.com> <56B46C3302000078000CEDF4@prv-mh.provo.novell.com> <012513b81f7b4da9af251d942ebae66c@AMSPEX02CL03.citrite.net> <4d9512d6068946e0921a784705f2d3f4@AMSPEX02CL03.citrite.net> <56C3092302000078000D28BE@prv-mh.provo.novell.com> <18f9277a243247739d1565f71accca8f@AMSPEX02CL03.citrite.net> <56C457F302000078000D303C@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56C457F302000078000D303C@prv-mh.provo.novell.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: Jan Beulich , Paul Durrant , Kevin Tian , Zhang Yu Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , "xen-devel@lists.xen.org" , Stefano Stabellini , Zhiyuan Lv , IanJackson , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org On 17/02/16 10:22, Jan Beulich wrote: >>>> On 17.02.16 at 10:58, wrote: >> Thanks for the help. Let's see whether we can have some solution ready for >> 4.7. :-) > > Since we now seem to all agree that a different approach is going to > be taken, I think we indeed should revert f5a32c5b8e ("x86/HVM: > differentiate IO/mem resources tracked by ioreq server"). Please > voice objections to the plan pretty soon. FWIW, after this discussion, I don't have an objection to the basic interface in this series as it is, since it addresses my request that it be memory-based, and it could be switched to using p2m types behind-the-scenes -- with the exception of the knob to control how many ranges are allowed (since it exposes the internal implementation). I wouldn't object to the current implementation going in as it was in v9 (apparently), and then changing the type stuff around behind the scenes later as an optimization. I also don't think it would be terribly difficult to change the implementation as it is to just use write_dm for a single IOREQ server. We can rename it ioreq_server and expand it later. Sorry if this wasn't clear from my comments before. A new interface that's been carefully thought through would of course be nice too. -George