Re: [Xen-devel] [PATCH 3/4] move XENMEM_add_to_physmap_range handling framework to common code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.12.13 at 11:48, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Wed, 2013-12-18 at 14:35 +0000, Jan Beulich wrote:
>> There's really nothing really architecture specific here; the
>> architecture specific handling is limited to
>> xenmem_add_to_physmap_one().
>> 
>> Note the restriction of XENMAPSPACE_gmfn_range only being supported
>> through XENMEM_add_to_physmap is being dropped as being pointless.
> 
> Note that this will still not work on ARM where add_to_physmap_one()
> does not support the gmfn_range and will still return ENOSYS.
> 
> If you are dropping this restriction then xen/include/public/memory.h
> will need updating (likewise the first patch).

I don't think so - we can very well say certain combination are
unsupported even if they happen to work. That leaves us with
the option of dropping back to the earlier state should there
be a need.

> Personally I think that having two redundant ways of doing the same
> thing is the more pointless of the two. Especially given the need to
> think a bit carefully about what XENMEM_add_to_physmap_range
> XENMAPSPACE_gmfn_range might mean...

Yes, that combination is bogus whichever perspective you take.
To some degree also because "range" in the former name is really
wrong - the operation doesn't deal with a range, but with a group
(batch) of individual pages.

However, I meanwhile realized that from an interface perspective
(I'm not proposing to implement this right now!) the combination
could actually be made work - the errs array (being an output only
at present) could be re-used to serve as input to pass the sizes.
The main issue of implementing this would be how to deal with the
two necessary layers of preemption.

So I'm going to re-add the check.

Jan


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