[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.