Re: [Xen-devel] [PATCH 0/4] fix preemption handling for XENMEM_add_to_physmap_range{, _range}

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-12-18 at 14:29 +0000, Jan Beulich wrote:
> The hypervisor isn't supposed to use the input structures for
> storing continuation information - only fields explicitly used as
> hypercall outputs should ever be updated.
> 
> Obviously this implies an ABI change, but since the previous
> behavior was not intended to be that way I don't think we should
> stick to the old behavior.

FWIW I don't think adding const to a function parameter (which is
kinda-sorta what we are doing here) constitutes a change to the ABI as
such (or not a meaningful one), since a non-const can always be const'ed
on call.

> There's one caveat though - with the previous model, the caller
> could - upon failure - use the updated structure to find out how
> by progress was made. However, that wasn't intended afaict,
> largely supported by this information depending on hypervisor
> internals (i.e. the caller would have to know the order of request 
> processing and the meaning of the respective size fields, which
> aren't simply saying "this much was processed").

IIRC the long standing user of the original physmap range functionality
was hvmloader (something to do with batching IOMMU TLB flushes?). If
hvmloader isn't introspecting hypervisor internals in this way I doubt
anyone else is.

I suppose this series is proposed for 4.5 rather than 4.4 since you
didn't say otherwise?

> 
> Consequently, as a follow-up we may want to consider making
> explicit (and straight forward) this progress indication on error.
> 
> 1: move XENMEM_add_to_physmap handling framework to common code
> 2: fix XENMEM_add_to_physmap preemption handling
> 3: move XENMEM_add_to_physmap_range handling framework to common code
> 4: fix XENMEM_add_to_physmap_range preemption handling
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 



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