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