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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.07.15 at 13:17, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Tiejun Chen writes ("[Xen-devel] [v5][PATCH 01/16] xen: introduce 
> XENMEM_reserved_device_memory_map"):
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> 
>> This is a prerequisite for punching holes into HVM and PVH guests' P2M
>> to allow passing through devices that are associated with (on VT-d)
>> RMRRs.
> ...
> 
> This function:
> 
>> +++ b/xen/common/compat/memory.c
> ...
>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
>> +                                      u32 id, void *ctxt)
> 
> is remarkably similar to this function
> 
>> +++ b/xen/common/memory.c
> ...
>> +static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
>> +                                      u32 id, void *ctxt)
> 
> 
> 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.

>> +/*
>> + * 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?

Jan


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