From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3] x86/p2m: use large pages for MMIO mappings Date: Mon, 18 Jan 2016 17:00:24 +0000 Message-ID: <1453136424.6020.200.camel@citrix.com> References: <569780BD02000078000C6A1E@prv-mh.provo.novell.com> <1452852565.32341.51.camel@citrix.com> <5698DC6502000078000C72F9@prv-mh.provo.novell.com> <1452866222.6020.8.camel@citrix.com> <569912A302000078000C75A5@prv-mh.provo.novell.com> <1452869729.6020.22.camel@citrix.com> <569CAC5502000078000C7CB2@prv-mh.provo.novell.com> <1453134721.6020.180.camel@citrix.com> <569D263702000078000C82AA@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aLDAK-0007gA-6y for xen-devel@lists.xenproject.org; Mon, 18 Jan 2016 17:00:28 +0000 In-Reply-To: <569D263702000078000C82AA@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 Cc: Kevin Tian , Wei Liu , Stefano Stabellini , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , Jun Nakajima , xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Mon, 2016-01-18 at 09:51 -0700, Jan Beulich wrote: > > > > On 18.01.16 at 17:32, wrote: > > I must confess I'm not entirely following what the various proposals > > are, > > What is currently implemented by the patch is that, upon error on > iteration N the hypervisor would clean up on a best effort basis and > return the error indicator. In the alternative suggested model it > wouldn't do any cleanup and return N to indicate how far success > was seen; only in the event that N=0 would an error code be > returned. > > > but FWIW I have no in-principal problem with the caller (by which I > > think > > you mean the tools?) > > Yes. > > > having to cleanup partial success in order to allow > > incremental attempts to set things up with smaller and smaller page > > sizes. > > Except that in the new x86 model we're not talking about decreasing > page size, but just the splitting the hypervisor does in place of true > preemption. Decreasing page size would actually be harmful to the > goal of using large pages for the mappings. Ah, I assumed it was to allow things to progress if no large pages were actually around. Doing it for preemption purposes sounds ok too I guess. Ian.