From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Wed, 17 Feb 2016 11:12:51 +0000 Message-ID: <81c831a07f414a70a7e40e865654a757@AMSPEX02CL03.citrite.net> 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> <56C45319.9010908@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56C45319.9010908@citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Jan Beulich , Kevin Tian , Zhang Yu Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , "xen-devel@lists.xen.org" , Stefano Stabellini , Zhiyuan Lv , Ian Jackson , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: George Dunlap [mailto:george.dunlap@citrix.com] > Sent: 17 February 2016 11:02 > To: Jan Beulich; Paul Durrant; Kevin Tian; Zhang Yu > Cc: Andrew Cooper; Ian Campbell; Ian Jackson; Stefano Stabellini; Wei Liu; > Zhiyuan Lv; xen-devel@lists.xen.org; George Dunlap; Keir (Xen.org) > Subject: Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter > max_wp_ram_ranges. > > 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. > The problem is that, since you objected to wp_mem being treated the same as mmio, we had to introduce a new range type to the map/unmap hypercalls and that will become redundant if we steer by type. If we could have just increased the size of the rangeset for mmio and used that *for now* then weeks of work could have been saved going down this dead end. Paul > A new interface that's been carefully thought through would of course be > nice too. > > -George