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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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