Re: [Xen-devel] [v5][PATCH 01/16] xen: introduce XENMEM_reserved_device_memory_map

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [v5][PATCH 01/16] xen: introduce 
XENMEM_reserved_device_memory_map"):
> On 07.07.15 at 13:17, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> >> +/*
> >> + * With some legacy devices, certain guest-physical addresses cannot 
> >> safely
> >> + * be used for other purposes, e.g. to map guest RAM.  This hypercall
> >> + * enumerates those regions so the toolstack can avoid using them.
> > ...
> >> +    /* IN/OUT */
> >> +    unsigned int    nr_entries;
> > 
> > Perhaps I am missing something but I can't find any API documentation
> > for the return value and error returns from this new hypercall.
> 
> I think this is in line with everything else in this header - am I
> overlooking something?

In particular, wouldn't it be sensible to write down that if the
number of entries available is bigger than nr_entries, the hypercall
fails with ERANGE, sets nr_entries to the real number of entries, and
leaves the buffer in an undefined state ?

> > This function:
...
> > is remarkably similar to this function
...
> > Is this usual in hypervisor code ?  It may be that this is the general
> > approach in compat code and that any cure would be worse than the
> > disease, but I found it very striking.
> 
> The types involved are slightly different, and hence folding them
> isn't as easy as it might seem.

Fair enough.

Ian.

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