Re: [Xen-devel] [PATCH v3] x86/p2m: use large pages for MMIO mappings

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2016-01-18 at 01:11 -0700, Jan Beulich wrote:
> > > > On 15.01.16 at 15:55, <ian.campbell@xxxxxxxxxx> wrote:
> > On Fri, 2016-01-15 at 07:39 -0700, Jan Beulich wrote:
> > > I don't think I agree - there are two models. The meaning of
> > > -E2BIG for the caller to retry with a smaller amount doesn't exist in
> > > the new model anymore, and hence libxc wouldn't need to deal
> > > with that case anymore if the ARM side got updated too.
> > 
> > If ARM still has this behaviour then it is still part of the interface
> > IMHO, whether or not x86 chooses to use this particular possibility or
> > not.
> 
> Okay, that's a valid perspective.
> 
> > > ÂWhereas
> > > positive return values don't exist in the present (prior to the
> > > patch)
> > > model.
> > 
> > If there were two models in the way you suggest then there would surely
> > be
> > an ifdef somewhere in libxc. The fact that the two behaviours can
> > coexist
> > means to me that they are two halves of the same model (irrespective of
> > arch code opting in to different halves, and irrespective if having
> > updated
> > ARM there are then fewer possible error cases and a follow up
> > simplification to libxc).
> 
> Same here.
> 
> > Anyway, the current three-bullet point description of the new ABI in
> > the
> > commit message is clearly insufficient for the complexity whether we
> > want
> > to split hairs about how many models there are here or not.
> > 
> > At the very least the interface (_all_ aspects of it) should be
> > thoroughly
> > described in domctl.h next to XEN_DOMCTL_memory_mapping (which I just
> > noticed describes E2BIG and isn't changed here at all).
> 
> I can certainly do that, but I'd like to avoid doing this for the current
> model before having taken a decision on whether to instead use the
> alternative described in the post-commit message issue list. In fact,
> the more I think about it, the more I'm convinced that the alternative
> provides the more consistent interface, no matter that it leaves more
> of the (cleanup) work to the caller.

I must confess I'm not entirely following what the various proposals are,
but FWIW I have no in-principal problem with the caller (by which I think
you mean the tools?) having to cleanup partial success in order to allow
incremental attempts to set things up with smaller and smaller page sizes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel