[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v5][PATCH 01/16] xen: introduce XENMEM_reserved_device_memory_map
>>> On 07.07.15 at 15:23, <Ian.Jackson@xxxxxxxxxxxxx> wrote: > 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 ? I can add a sentence to that effect. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |